Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] About project properties.

I wish this was so easy.  What do you do, for example, when a standard 
make project builds more than one executable, or the same executable for 
multiple targets.  Providing a single list of symbols, inclusion paths and 
libraries doesn't make sense for this builder.  Really, the only reason 
we've done it for inclusion paths and symbols is to help get the parser up 
and running in the short term.  Ideally, we should be getting this 
information out of the makefile, somehow...

In my journey to define a build model, I have come to the realization that 
make (and gnu make in particular) does an unbeatable job at controlling 
builds for C/C++ projects.  That's why, in the end, we're concentrating on 
a managed make build which, essentially, helps make it easier to create 
makefiles but through UI or automation.  Anything else would much less 
than the expressive power that make gives you, particularly with its 
implicit rules and magic macro substitution (you can't beat OBJS = 

I've attached the first draft of my build model doc.  Comments are more 
than welcome.  If anyone has trouble with Word format, please let me know 
and I'll rush an HTML version out.

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada

"Alain Magloire" <alain@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
07/07/2003 03:29 PM
Please respond to


Re: [cdt-dev] About project properties.

> I guess that is the major problem with the CBuilder concept.  In the 
> there is very little that can be shared between the builders, so why 
> bother.
> My intention is to create a nature for the standard make builder and a 
> nature for the managed make builder.  The paths and symbols page will 
> appear with standard make.  A much more complicated page will appear for 

> managed make.  Neither will appear if neither nature is there.  I still 
> have to figure out a way to upgrade existing standard make projects with 

> the new nature automatically without applying it to the QNX builder.
> Thoughts?

This is one reason, at least at the beginning, we've been pushing for a 
"build model"
Where "build model" is a set of simple interfaces that a "CDT Builder" 
must follow.
So whether the project has for builder:

"Standard Make builder"
"QnX builder"
"Managed Make"
"Timesys Builder"

So when the parser needs to grab the include paths:

                 String[] ICBuilder.getIncludePaths();

The debugger needs libraries

                 String[] ICBuilder.getLibraryPaths();

For "Standard Make" empty arrays will probably be return but the "Managed
Make" has all the infos.

I will officially ask later to create a new plugin
or something to move the standard make outside of the CDT.

Can we see if can come up with a common set of methods that all
builder should follow ?

cdt-dev mailing list

Attachment: CDT Build Model.doc
Description: Binary data

Back to the top