-----Original Message-----
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:
cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James
Blackburn
Sent: Saturday, April 24, 2010 9:30 AM
To: CDT General
developers list.
Subject: Re: [cdt-dev] Build Again
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>
>
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev