Re: [cdt-dev] Build Again

[James Blackburn <jamesblackburn@xxxxxxxxx>]

Hi Doug,

You're right: the CDT build-system is tough, the code quality leaves
something to be desired, and the way it's been written makes unit
testing hard, so instead there are brittle end-to-end tests.

That said it works today.

I spent last week fighting to make improvements for a team using
ManagedBuild in anger. One project set has 44 (yes really 44!)
inter-dependent projects. Most are libraries which are brought
together using references to build the top-level app.  It works
remarkably well but a there are a few problems: bug 309769 and
friends...

I worry that years have been put into the current build system, and
that it would be impossible with current resourcing to recreate the
functionality.  And if we were to re-create it, would we just end up
with the same issues and same problems as before?  Taking debug as a
topical example: there are now 3 debug engines, each with pros and
cons and each with committers addressing similar issues. As a user I'm
not really sure why I'd choose one over the other. While it's good
there's choice, in my mind choice creates confusion, and wastes
effort.

The wiki makes some great points.  One thing it doesn't mention is how
to go about solving the complexity of the build model. Currently it's
hugely verbose (in terms of lines of code, size of a .cproject, size
of the build system schema) and a huge PIA to maintain.  I can't help
but feeling that EMF might make this all easier -- if only I knew
anything about it.

Rather than starting from scratch, would it be better to start from
where we are now, work out where the pain-points are and push for
improvements in these areas?  That way we make what we have better
rather than taking the risk of starting from scratch and not having
enough momentum to carry it through.

At the moment I'm pretty invested in the MBS. We have two teams using
it for their projects, and 1 team using Make Targets and standard
make.  Unless the project leads give up on it, I can't see myself
getting much time to work on something completely new.

Cheers,
James


On 24 April 2010 16:05, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
> Hey gang, FYI,
> As I mentioned on the last call, I've been asked to play a more active role
> in TCF and help build a community for it and work with you to bring it to
> maturity. That's taking most of my time these days as I get up to speed and
> figure out what we need to do with it.
> In my spare time, I'm working on bringing the CDT to the Android community
> to help build native libraries for that platform. The focus is on one of my
> dream projects, building a game engine out of open source parts, in this
> case for Android, but I have eyes on iPhone and MeeGo too. Part of doing
> that is getting the Android gnu toolchain working well with CDT. And that's
> brought me back into the CDT build nightmare. Once again, I am having a hell
> of a time getting scanner discovery working for these seemingly simple
> Makefile projects. Just look at a stack trace sometime and you'll see,
> today, the CDT build system is the opposite of simple.
> So I am urging myself to get back into working on a new build system. We
> need to put the architecture back to the way it was, with managed build
> being an add-on, not having everything driven by managed build. Obviously,
> I'm not going to have much time to spend on it, so by definition, I'll have
> to keep it simple. And I'll have to do it as a separate stack, not as an
> evolution of what we have.
> Over the next few days, I'll jot down some more ideas
> here http://wiki.eclipse.org/CDT/NextGenBuild. And I'll recreate cdt.build.*
> plug-ins, this time in a separate folder to avoid confusion. And as always
> help is appreciated and hopefully, I'll have new found vested interest in
> bringing it to completion, especially since I want to get back working on
> the Android project.
> Cheers,
> Doug
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>