Skip to main content
[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

Back to the top