Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] RIP Wascana, Build System discussion

> I'm not sure though that the MBS was ever built to support integrations like this. It was intended to behave just as Visual C++ does, which also doesn't deal well with external build tools. It's important that we keep that in mind.

We didn’t consider building outside of CDT enough in the MBS design.  I guess the thought was that you could take the generated makefile and use that outside of Eclipse.  I don’t know if that works at all in practice.

 

In the last major build model update, Mikhail Sennikovsky tried to separate out a generic build model from the MBS.  There are pieces of functionality that are not MBS specific, for example allowing a tool chain to specify an “environment provider” for any build system.  

 

By the way, VC++ will play nicely with external builds in VS 2010.  A VC++ 2010 project file is an MSBuild file and so can be used directly by MSBuild outside of Visual Studio.  VC++ also has a new method of integrating another C++ toolset.  It’s not as flexible as MBS and is almost exclusively “declarative” – you have to write XML files using the MSBuild schema and XAML files to describe property pages.

 

Leo

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Friday, May 22, 2009 7:56 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] RIP Wascana, Build System discussion

 

 

On Fri, May 22, 2009 at 4:34 AM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:

On Fri, May 22, 2009 at 9:05 AM, Jesper Eskilson <jesper.eskilson@xxxxxx> wrote:
>
> - It does not have any decent support for offline/headless builds.
> - It integrates badly with other build systems. If you build your code base
> around MBS, you force people to use CDT. This makes CDT/MBS a much harder
> sell than if CDT was easy to integrate with other build systems.

This is one of the killers for the Eclipse plugin build process as
well. It's pretty much impossible to do decent headless builds outside
of Eclipse (and the build.xml is painful to the extreme) but it pretty
much ties you/inhibits you to do things the way PDE is expecting
(META-INF at root of plugin etc). That's one of the reasons you don't
see much OSGi dev outside of the Eclipse space.

So as nice as having an internal build system is, having the ability
to run builds externally (and with independent tools) is also a good
way of supporting a build process. It would be interesting to know how
CDT would do in e.g. the face of './configure' type scripts which
generate a bunch of these things on the fly - a GUI wrapper around the
args needed for the ./configure script woul dbe handy.


Interesting enough the Red Hat guys have an Autoconf plugin which does exactly that. My effort on the Makefile project side will take that into account and make sure the workflows are clean.

I'm not sure though that the MBS was ever built to support integrations like this. It was intended to behave just as Visual C++ does, which also doesn't deal well with external build tools. It's important that we keep that in mind.

And that's why I want to make it easier, or even provide integrations for these external build tools to make it easier for users to adopt. But it won't be based on MBS. I think it would be very difficult to push the build model to do these kind of things. I saw Jeff from Red Hat try with his autoconf thing. It wasn't pretty.

Doug.


Alex

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


Back to the top