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

Bug 335001

Summary: Copying a configuration persists previous exported library path
Product: [Tools] CDT Reporter: James Blackburn <jamesblackburn+eclipse>
Component: cdt-build-managedAssignee: Project Inbox <cdt-build-managed-inbox>
Status: NEW --- QA Contact: Jonah Graham <jonah>
Severity: normal    
Priority: P3 CC: cdtdoug, yevshif
Version: 8.0   
Target Milestone: ---   
Hardware: PC   
OS: Linux-GTK   
Whiteboard:
Attachments:
Description Flags
patch 1 jamesblackburn+eclipse: iplog-

Description James Blackburn CLA 2011-01-21 07:22:34 EST 
A couple of bugs here:

  - Creating a new configuration from an exsiting one, doesn't remove the previous exported library path.  
  - Renaming a project doesn't update the exported settings.

Similar to bug 230165 where the artifact name doens't change when project is renamed. Exported settings are hard-coded to match the current project name and artifact name.  Instead it would be better if they used the ${ConfigName} and ${ProjName} variables as Andrew suggested in bug 328363.  That way the settings should always be in sync with the current configuration.
Comment 1 James Blackburn CLA 2011-01-21 08:40:14 EST 
Created attachment 187282 [details]
patch 1

Patch for the first issue.
  - Creating a configuration from an existing configuration resets the exported settings on the new configuration to defaults.

Fixing this issue is hard in the current model.  All exported settings are glommed together in the configuration.  So it's impossible to tell custom, user provided exports, from built-ins (see ICConfigurationDescription#get/setExternalSettings).

Ideally the entire external settings feature should be built on top of the new Scanner Discovery.  Having N different API hooks for each path and symbol is crazy.
Comment 2 James Blackburn CLA 2011-01-21 09:14:56 EST 
Same is true for a configuration rename.