Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 335338

Summary: Configurations from projectTypes are included in ManagedBuildManager#getExtensionConfigurations
Product: [Tools] CDT Reporter: James Blackburn <jamesblackburn+eclipse>
Component: cdt-buildAssignee: James Blackburn <jamesblackburn+eclipse>
Status: RESOLVED FIXED QA Contact: Andrew Gvozdev <angvoz.dev>
Severity: normal    
Priority: P3 CC: cdtdoug, ilg
Version: 8.0Flags: jamesblackburn+eclipse: review? (angvoz.dev)
Target Milestone: 8.0   
Hardware: PC   
OS: Linux-GTK   
Whiteboard:
Attachments:
Description Flags
patch 1 jamesblackburn+eclipse: iplog-

Description James Blackburn CLA 2011-01-25 11:32:02 EST
I have a number of project types which collect together a number of configurations. The project type configurations use mixed toolchains so I can create projects that build both natively and for an embedded target.

However when I create a standard templated project, using the basic exe, library, ... template, the configurations created on the project are the superset of all applicable configurations  (matching build artifact type) taken from all projectTypes.  This is very weird, as I would have thought that configurations under project types shouldn't be included.

This happens as a result of:

ManagedBuildManager.getExtensionConfigurations(IToolChain, String, String) line: 4141	
MBSWizardHandler.addTc(IToolChain) line: 524	
ManagedBuildWizard.createItems(boolean, IWizard) line: 61	
CDTMainWizardPage.updateData(Tree, Composite, Button, IWizardItemsListListener, IWizard) line: 291	
CDTMainWizardPage.createControl(Composite) line: 93	

Note that there's an equivalent method for discovering configurations from a project type.

This method returns all configurations matching a specific property type (in this case: artefact type). Obviously my configurations under the project type are registered for producing artifacts.
Comment 1 James Blackburn CLA 2011-01-25 12:21:18 EST
Created attachment 187546 [details]
patch 1

Patch for the issue.

Like the ManagedBuildWizard, we ignore the configurations under named ProjectTypes when creating a project from an 'MBSWizardHandler.ARTIFACT' type template.

These configurations will be present when creating project type typed projects.
Comment 2 James Blackburn CLA 2011-01-25 12:28:10 EST
I think the important thing here is not to break existing functionality, nor assumptions that other integrators may make. I believe the patch is safe in this regard.  If you could cross-check Andrew.
Comment 4 Andrew Gvozdev CLA 2011-01-26 15:27:22 EST
I am unsure about assumptions other integrators make but I checked our own. We have customized wizards and project types and they still work. We use empty artifact though (unmanaged projects) but our buildDefinitions is pretty detailed.
Comment 5 James Blackburn CLA 2011-01-26 15:36:02 EST
(In reply to comment #4)
> I am unsure about assumptions other integrators make but I checked our own. We
> have customized wizards and project types and they still work. We use empty
> artifact though (unmanaged projects) but our buildDefinitions is pretty
> detailed.

Yes, that's right. The empty projectType name is treated as 'magic' and new-style i.e. they're added automatically to the relevant artifact type templated projects.  Without this change, every configuration from every other named project type is also added automatically by the wizard.  
The result is way too many configurations in the default wizards for people using custom project types.
Comment 6 Andrew Gvozdev CLA 2011-09-06 17:20:05 EDT
(In reply to comment #2)
> I think the important thing here is not to break existing functionality, nor
> assumptions that other integrators may make. I believe the patch is safe in this
> regard.  If you could cross-check Andrew.
8 months later, I finally stumbled upon a regression caused by this change, see bug 356864.
Comment 7 Liviu Ionescu CLA 2011-11-20 13:38:08 EST
(In reply to comment #6)
> 8 months later, I finally stumbled upon a regression caused by this change, see
> bug 356864.

I confirm that reverting CDTConfigWizardPage.java from e7395 to previous 7220a
fixes the problem I experienced with the GNU ARM Plug-in, reported as bug 356111.

Liviu