I’m going to put some specific suggestions together along
the lines of my comments below. Scanner discovery was never part of the
MBS and that’s part of the problem.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
Of Andrew Gvozdev
Sent: Sunday, April 25, 2010 9:38 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Build Again
Hi Doug,
I think currently standard make project is hurt being an instance of an
overweight MBS project. MBS took over everything related to build including
project model squashing any competitor build system with impenetrable
complexity. If we could make MBS a build system among others it would be a good
thing. MBS is very useful and working well for the most part, but those parts
that are not working properly, such as scanner discovery, near impossible to
fix.
A while ago I wrote a prototype for new scanner discovery (bug 290631).
For all the talk I never got much feedback on that. I planned to continue that
work after Helios release. Perhaps I can give you a hand with the new build
system on scanner discovery along these ideas? And if it proves itself we could
back-port it back to MBS.
BTW, perhaps you could create a git repository for the new-build plugin rather
than CVS - to try it out before potential move of CDT ones?
Andrew
On Sat, Apr 24, 2010 at 4:26 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
Thanks guys. I'll definitely use your input.
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. And I think the problem is architectural, not
code quality. Standard make projects used to be very simple. Yes, we needed
them to do more, but they still should be simple.
My focus will be on making it easier to get projects that
use Makefiles and/or external managed build systems like configure, qmake, and
cmake up and running including automatically setting up build environments and
scanner discovery. I certainly won't be replacing CDT's managed build in the
short term. It works well enough, and I only have so many hours to spend on
this. And given the pervasiveness and quality of Make and the external managed
build systems, I'm not even sure it's needed any more.
:D
On Sat, Apr 24, 2010 at 2:02 PM, Treggiari, Leo <leo.treggiari@xxxxxxxxx>
wrote:
Putting together a fully customizable managed build system
was complex and I guess it shows.
See http://www.ddj.com/dept/opensource/197002115
for an exaqmple of its flexibility.
That said, I would suggest that the first step is this. Cleanly separate
the "create a makefile or other build system file" functionality of
the MBS from the basic build functionality. My belief is that all build
systems added to CDT can gain by much of the functionality at the TOP of the
MBS schema - objects like Projects, Configurations, ToolChains. The
ability to specify information such as how to set up the build environment for
a toolchain or provide the information needed by the editing functionality of
CDT is invaluable to a multi-toolchain environment such as CDT - even Visual
Studio finally provides the ability to set up a tool-chain specific environment
in VS 2010. And, then resolve how Scanner discovery interacts with this
basic tool-chain integration functionality - that clearly was never done properly.
The information from the TOP of the MBS schema could be provided in a new
schema and the MBS schema evolved to the pieces required for generating a build
file or implementing an internal builder. Or maybe some clean split can
be accomplished with the current schema.
Thanks for listening,
Leo
-----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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
