Regarding building outside CDT, here some ideas based on use cases in our embedded (Symbian
and Linux) products, which could make CDT more friendly to external build
variously, autotools (though not Jeff's autotools builder, for reasons
mentioned by Doug), qmake, make, and Symbian's build system, but want
stronger and more unified UI integration. We've had to do a lot
of custom and repetitive work for this.
What if, instead of a completely hands-off model, like the
standard make model where the user manually edits Makefiles in an editor, or a completely automated model
like MBS that involves full control of compiler/linker invocation, there were an external build model that
provides architecture for wrapping existing build systems, such as autotools,
qmake, scons, etc. and integrating the build
system's model into the UI?
The goal of such a model, as others
have mentioned, would be to let the user switch back and forth
between the IDE and the command line freely and to let the user share projects from
source control with developers not using IDEs. But
unlike standard make or managed make, it should automate the updating of build scripts from resource changes and update build configuration
data from build script changes, without completely taking over
the work of the build system or relying on build-time parsing to gather
In addition to
the build support, there should be UI integration support
for a custom common project navigator model derived from
the build scripts. I.e. the external build system should be able
to influence or control the way the CDT project navigator model is
generated. We're still hammering out UI issues with presenting the project
model that's really built versus the tree of files that happen to
be living in the project directory. CDT's source folders alone don't cut
it as an organization strategy :) We've resorted to ancillary views
for this, reinventing the wheel to attach copy/rename/move/build actions,
support filtering, etc (gahh).
The builder support, I
be minimal: a custom command-line builder,
similar to the standard make builder, which controls the build by invoking the
external tool with build scripts/files from the project. It could handle incremental/full/clean
builds similarly to standard make as well,
with appropriate vendor
Extensions would be implemented and invoked by CDT
to (1) handle synchronizing changes between the
resource model and the build scripts by interpreting resource change
events, (2) generate build configuration
data and indexer settings by parsing build scripts, (3) react to modification, creation, and deletion of build scripts, (4) analyze resource change events to determine
whether a recompile or relink or reindex is needed, and (5) generate/modify the CDT's project navigator
These extensions, in fact, need not be tied whatsoever
to the external build model.
Of course, a lot of
work must go into the implementation of the extensions, to handle parsing and rewriting build
scripts. But by being standard extensions to CDT, standard
implementations could be written once
(e.g. managed make + standard make, autotools,
Would it be appropriate for CDT to provide support
like this? Were you thinking something along these
> 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.
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Friday, May 22, 2009 7:56
To: CDT General developers list.
Subject: Re: [cdt-dev] RIP Wascana, Build
On Fri, May 22, 2009 at 4:34 AM, Alex Blewitt <alex.blewitt@xxxxxxxxx>
On Fri, May 22, 2009 at 9:05 AM, Jesper
> - It does not have any decent support for
> - 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
well. It's pretty much impossible to do decent headless builds
of Eclipse (and the build.xml is painful to the extreme) but it
much ties you/inhibits you to do things the way PDE is
(META-INF at root of plugin etc). That's one of the reasons you
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
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