Skip to main content

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

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

Back to the top