| 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 =
$(SRCS:$(ROOT)%.c=%.o)).
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.
Cheers,
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
cdt-dev@xxxxxxxxxxx
To
cdt-dev@xxxxxxxxxxx
cc
Subject
Re: [cdt-dev] About project properties.
>
> I guess that is the major problem with the CBuilder concept. In the
end,
> 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
only
> 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"
etc..
...
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
org.eclipse.cdt.make
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
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
Attachment:
CDT Build Model.doc
Description: Binary data