[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Revised Build Model Scanner Info Discovery Mechanism
|
Sounds great... just some comments below...
Sean Evoy wrote:
Hi All,
Long title; simple problem. As you may recall, a couple of weeks ago I
asked for feedback on the way the build model clients discovered a
builder and extracted information about the current build settings. At
the time, I had submitted a solution based on an extension point.
Build managers registered through the "ScannerInfoProvider" extension
point. Clients iterated over all the build managers that were defined
and asked if the supplied build information for a given project.
During our build conference call, QNX suggested using the
CExtensionPoint mechanism instead. The advantage being that the build
managers registered themselves directly with a project when it is
created so no iteration is required.
What I am looking for is a go/no-go on the new discovery mechanism
described below. I would like to submit the code soon so the Indexing
service can begin to use the "real" interface instead of the
hard-coded solution that is currently in effect.
In order to work through CExtensionPoint mechanism, I have to change
the existing extension point entries for the Managed and Standard
builders to the following (all future builders will have to conform to
this as well):
<extension
id="ManagedBuildManager"
point="org.eclipse.cdt.core.ScannerInfoProvider">
<cextension>
<run
class="org.eclipse.cdt.core.build.managed.ManagedBuildManager">
</run>
</cextension>
</extension>
<extension
id="StandardBuildManager"
point="org.eclipse.cdt.core.ScannerInfoProvider">
<cextension>
<run
class="org.eclipse.cdt.core.build.standard.StandardBuildManager">
</run>
</cextension>
</extension>
As well, the ManagedBuildManager and StandardBuildManager must extend
AbstractCExtension.
The new project wizards for managed and standard projects have to be
modified to register the right class as the scanner info providers for
the project. The example below shows the managed project wizard code,
but the standard project wizard is similar.
try {
ICDescriptor desc =
CCorePlugin.getDefault().getCProjectDescription(project);
desc.remove(CCorePlugin.BUILD_SCANNER_INFO_UNIQ_ID);
desc.create(CCorePlugin.BUILD_SCANNER_INFO_UNIQ_ID,
ManagedBuildManager.INTERFACE_IDENTITY);
} <snip>
This can be done in the configure/update method of the ICOwner when a
cproject is created, you can see how the C project
creation invokes this, simple return you owner id from getProjectID in
the CProjectWizard. Take a look at the CProject extension
and MakeProject for an example.
Clients use a new method defined in CCorePlugin to get the information
provider as shown in the updated JUnit test code below:
// Find the first IScannerInfoProvider that supplies build info for
the project
IScannerInfoProvider provider =
CCorePlugin.getDefault().getScannerInfoProvider(project);
assertNotNull(provider);
As is the case now, clients implement the IScannerInfoChangeListener
interface and pass themselves to the provider in a subscription
message. There is also a new method on the IScannerInfoProvider
interface that allows the client to get information immediately as
shown below:
IScannerInfo currentSettings = provider.getScannerInformation(project);
The ManagedBuildManager::getScannerInfo(IResource) method will be
deprecated, then removed before the end of this release cycle.
I would appreciate feedback on this as soon as possible. Obviously,
Bogdan is the immediate client of this code, but Dave Inglis will also
be effected. I have made changes to all the relevant classes in the
standard and managed build systems. If we are in agreement that this
is the way to proceed, I will submit those changes. Thanks,
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada