> Would it be appropriate for CDT to
provide support like this?
I would say, absolutely!
> 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.
I think this is an important point and is a significant
difference between the developer communities where CDT has been more successful
(particularly embedded software development) and Windows. On Windows, developers
are quite used to the IDE handling the build, and as Doug mentioned, this was
the goal of the MBS.
> 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 configuration
data.
Well put. There has always been a “tension”
in CDT over how the edit-time/design-time configuration information is gathered
vs. the build-time configuration data. We made a few efforts at coordinating
this, assigning the responsibilities to a single appropriate party etc., but I
don’t get the feeling that this problem has ever been solved correctly.
> 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 don’t know as much about this part of your proposal.
It sounds related to the basic resource/file model changes that CDT has been
driving in Eclipse.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed.Swartz@xxxxxxxxx
Sent: Friday, May 22, 2009 9:15 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] RIP
Wascana, Build System discussion
Hi all,
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 systems.
We use, 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 configuration
data.
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 think, would
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 configuration.
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 model.
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, qmake, etc).
Would it be appropriate for CDT to provide
support like this? Were you thinking something along these lines?
From: Treggiari, Leo [mailto:leo.treggiari@xxxxxxxxx]
Sent: Friday, May 22, 2009 10:27
AM
To: CDT
General developers list.
Subject: 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