Bug 304005 - Rename build configuartion loses configuration
Summary: Rename build configuartion loses configuration
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Autotools (show other bugs)
Version: 0.4.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 0.5   Edit
Assignee: Jeff Johnston CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-26 04:36 EST by Jens Seidel CLA
Modified: 2010-03-15 12:07 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Seidel CLA 2010-02-26 04:36:13 EST
Build Identifier: 3.6.0 I20100129-1300 (M5)

Hi,

I noticed that with the new autotools code a renamed build configuration loses all configuration such as configure flags, build directory, ...

Reproducible: Always
Comment 1 Jeff Johnston CLA 2010-02-26 18:28:35 EST
Just to let you know I am working on this.  It requires some redesign on my part to work properly across the CDT Property pages.
Comment 2 Jeff Johnston CLA 2010-03-12 19:04:14 EST
Fix has been checked in.  The design had to be changed to store and reference Autotool configurations by id and not name.  This is because the name can be changed outside of the Autotools pages and to eventually figure out what the original configuration to copy is not possible by name under a number of scenarios (e.g. a double rename to an existing name).  The id of the configuration however does not change across a rename and so the data can be copied reliably regardless of how many renames are performed.  As a consequence of this, the .autotools file is less readable since the id is stored, not the configuration name.  The ids correspond to the configuration ids in the .cproject file.

An old .autotools file with name fields will still work.  After the next Apply or Ok, it will be saved with id fields instead.
Comment 3 Jens Seidel CLA 2010-03-15 09:42:24 EDT
(In reply to comment #2)
> An old .autotools file with name fields will still work.  After the next Apply
> or Ok, it will be saved with id fields instead.

I did so and lost my build directory settings as the default "build-debug", "build-release" was used. Nevertheless it was easy to fix.

I still had very many reordered lines in .autotools which makes viewing diffs very hard.
Comment 4 Jeff Johnston CLA 2010-03-15 12:07:27 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > An old .autotools file with name fields will still work.  After the next Apply
> > or Ok, it will be saved with id fields instead.
> 
> I did so and lost my build directory settings as the default "build-debug",
> "build-release" was used. Nevertheless it was easy to fix.
> 
> I still had very many reordered lines in .autotools which makes viewing diffs
> very hard.

I'll take a look at the build directory.

The reordering of options is to make them more predictable.  The internal logic uses a Java Map for the options and there is no guaranteed ordering for iteration.  To remedy this, a set ordering is used for extracting the options now.