If there is no match for an option in the project being converted, ignore the option and continue converting the configuration
Patch tool lookup in converters to handle the case where the location of the definition fools the manifest reader and effectively hides the tool
The fix involves changing the way the updater converts model element IDs. It now tests as best it can whether the element is built-in or not before looking it up and adding it to the new, 2.1 buld model for the project
44568 - [Managed Build] -Xlinker option requires space separator
80119 - [Managed Build] Error in the Xlinker option's generated output
The code and the manifest file have been changed to correctly deal with
the -Xlinker option. Multiple entries have separate -Xlinker options,
and there is a space between -Xlinker and the value. The space is
handled by the new option.command functionality - "${VALUE}".
77399 - Managed Make Builder mangles subdir.mk if configuration of
linked resource was changed
This was partially fixed before and was partially a user error.
Code has been added to output an error message to the console when
MBS sees a duplicate identifier in the loaded manifest files.
Partial fix:
80067 - [Managed Build] Wrong command for building in MMS
A fix has been added so that a command is not stored with a Tool
unless the user changes the value - i.e the Tool will inherit the
value from its suoer-class. There is still an error with the Gnu
makefile generator when a configuration tool and a resource
configuration tool have different commands specified by the user.
This will be fixed later.
1. [Bug 79451] NPEs on project import
2. [Bug 77399] Managed Make Builder mangles subdir.mk if configuration of linked resource was changed fix for initial problem additional problems to be investigated
3. Force rebuild when file build option changes
4. Ensure that converted projects get saved.
The 1.2 project stored the default project in the cdtbuild file so it was a matter of reading that it an cacheing a map of old config IDs to new, then setting the default using the appropriate new config
Fix for bugzilla 79572 -- Importing 1.2 projects with libraries/library search paths fails
The IDs for libraries and library search paths had an extra element that converter was not dealing with and the conversion was failing
The same logic applies to the refresh operation on referenced projects as it did for the problem markers. It is no longer necessary given the way the build is sequenced and this avoids needless thrashing in the workspace.
The patch contains a fix for Bug 69114. The particular problem was that the manifest file contained an invalid id in an optionCategory owner attribute. The patch contains a change to all appropriate resolveReferences methods to check for unresolved references and write out an error message. For the optionCategory owner attribute, the owner is set to the Tool by default.
Code to handle the case where a manifest file or project file contains a higher version number than the Managed Build System.
New JUnit tests for the new model.
Updates to some external strings.
Handles Managed Build System projects that fail to open or convert, for example, because the tool-chain that the project uses is not installed.
When a project configuration is removed, cleans the configuration output.
Edits for some of the externalized strings.
The majority of the code changes were for dealing with the Java class attributes (buildfileGenerator, etc ).
The other bug fixes were:
When the user displays the properties of a file in a standard make file, the C/C++ category is displayed in the left pane I couldnt figure out a way to filter it out. Before the fix, the Managed Make property page was displayed and would then crash when the user selected OK. Now, it displays a label saying that this page only applies to Managed Make projects.
When the user has automatic build set, edits the properties of a configuration, selects a different configuration, selects OK when asked to save the changes, a build for the proper configuration would start but it would pick up the tool settings from the wrong configuration (the newly selected one).
There was a bug in the Option.onlyOverridesValue method where it wasnt checking for a zero-length built-ins list, and therefore returning the wrong answer.
There was a bug in adding a Tool to a ToolChain where the new Tool was added to the toolList but not the toolMap.
