Re: [cdt-dev] Build Again

[James Blackburn <jamesblackburn@xxxxxxxxx>]

Thanks guys.

On 24 April 2010 21:26, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
> I will disagree with James statement that "it works today". I never been
> able to get scanner discovery to work for a new toolchain. I know Chris R
> has had a similar problem. If it did work today I wouldn't be so frustrated
> by it.

Perhaps I should have qualified that statement :).  I'm in complete
agreement with you about the issues you've highlighted.  [I've never
been able to use scanner discovery successfully, and only use it for
built-in discovery with some well-placed hacks to nuke existing
entries..]

Going back to build, much of the non-MBS specific bits of the model
are in cdt.core. In particular configurations are a core concept, as
are paths and symbols -- though this needs some serious work (as
above).

What would be great is if the Autotools guys, who've done an
integration most recently, chipped in with the pitfalls and issues
that prevent a smooth integration.

I take your point that there lots of great external build systems. And
I'm completely behind making it easier for external build systems to
integrate!  The easier it is for anyone to use CDT for their project,
the better it is for the community.

However I think it's valuable to also provide our own build system.
One where you can drop some source in and it builds without too much
fuss.  General purpose build systems are immensely powerful, and
anyone's who's tried to get their head around a really big make tree
can attest that gremlins linger and sooner or later the complexity
bites you.  Introducing new developers to this is hard, and everyone
relies on the build gurus with the knowledge.

With these two new projects we thought we'd give managedbuild a shot.
While Eclipse does provide a certain type of Java-centric
straight-jacket. The notion that developers separate out individual
unit-testable blocks of code into separate projects and bring all this
together has actually worked quite well.  It's reasonably
straightforward to teach someone where the build configuration
settings live, how to wire together configuration with references, and
use exports to propagate include / library path / and library
dependencies.
And because the system encourages modularity from the outset. It's
easy for any of the developers to reason about what's happening in the
build.  Yes it's not as flexible as an external build system. But it
does provide an immense amount of value, and consistency, out the box.

Granted it's not for everyone, and so I agree we need to make it easy
for extenders to plug-in their own. There's no reason why ManagedBuild
shouldn't be one of a number of well-integrated build systems!

Cheers,
James