Re: [cdt-dev] About project properties.

[Sean Evoy <sevoy@xxxxxxxxxx>]

Alain,
If you think about it, this is not a
ton of work. There is a clear dependency between the scanner and the build
information. You have pointed out that the debugger needs lib path information.
Finally, different build systems should provide wizards and property page
support that is appropriate. The nature defines what property pages get
shown, not the build system, so that really isn't part of the interface,
just part of the work.

> 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();
> 

My last patch added this via the IScannerInfoProvider
interface. Simply put, the build system registers as a provider using an
extension point. The client discovers the provider that manages a particular
project at runtime. Then, the client subscribes to, and receives information
from, the provider as settings change.

> The debugger needs libraries
> 
>    String[] ICBuilder.getLibraryPaths();
> 
> For "Standard Make" empty arrays will probably be return
but the "Managed
> Make" has all the infos.
> 

It's good to know this. This requirement has never
formally been articulated before now. If people are comfortable with the
way the scanner info is provided, we can look at doing something similar
for library paths.

> 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 ?

Well, yes and no. As I said, there are not a lot of
methods to implement. We can easily come up with the dozen or so methods
that are absolutely needed for the clients we can envisage. The real challenge
is going to be discovering which build model the client should talk to.
For scanner information, I have designed the system to use the project
as the key discriminator. So, once the client has a list of providers,
it asks each in turn if it manages a project. Earlier, it was mentioned
that we would like to have multiple build models managing one project.
This design would not work with a 1-to-many mapping.

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada