On Mon, Apr 26, 2010 at 12:37 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx
> wrote:
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.
Sorry I missed this Andrew, I will definitely take a look. I want
to make sure scanner discovery, which is critical for Makefile
projects, is easily extensible to other tool chains, cross gcc
compilers in particular and MSVC probably to ensure we're not too
gcc specific. I like the fundamentals of scanner discovery, i.e.
build output parsing and collecting like compiler commands to
ensure we can have scalable per file discovery. But we need make it
easier to extend.
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?
That's a good idea. I need to keep track of egit and using for
something real will help. I have an account on github and will set
up something there.
My strategy is to have a build.core and build.ui plug-in where we
can fork what we need so that we don't disturb existing stuff and
to help break the shackles. Scanner discovery should be one of
those things. It'll also have a new New Project wizard to set up
the project for the new build system.
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