Re: [cdt-dev] About project properties.

["Alex Chapiro" <achapiro@xxxxxxx>]

Of course all this methods are target dependent or let me say build
configuration dependent. That's why in our implementation they have build
configuration as a parameter. I realize that this is another difficult
question how to find general format for build configuration, but maybe it is
possible with accepting of some limitation.
And we use make itself to apply required build configuration to existing
make file and extract required parameters (such as include paths for
example) from it.
Thanks for the document publication.

Alex Chapiro

----- Original Message -----
From: "Douglas Schaefer" <dschaefe@xxxxxxxxxx>
To: <cdt-dev@xxxxxxxxxxx>
Sent: Monday, July 07, 2003 4:27 PM
Subject: 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
>
>