1. Bob Monteleone - initial Discrete Custom Build Step support
2. Mikhail Sennikovsky - initial isSupported support
3. Norbert Pleott - support list of binary parsers in targetPlatform binaryParser attribute
and 85229: Problem with scannerInfoCollector attribute in the toolChain schema of MBS.
Replaced ToolChain's attribute scannerInfoCollector with ScannerConfigDiscoveredProfileId in managed builder extension point definition schema. Discovery of compiler's internal scanner info for a manged project now uses specified SCD profile.
On Windows, specified profile calls cygpath to translate discovered paths.
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.
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.
1. For a String option, if the defaultValue attribute is present, and contains a string of length > 0, then the command string (if any) is prepended to the defaultValue string to form the command line string.
2. Add a commandFalse attribute to the Option Schema to be used, if specified, when the value of a Boolean option is False.
reference.
Changed the schema to allow a tool reference to belong to a target.
* schema/ManagedBuildTools.exsd
Changed the manifest logic in the managed build manager to load and
retrieve tool definitions as well as target definitions. The schema
allowed for this, but the logic was missing.
* src/org/eclipse/cdt/managedbuilder/core/ManagedBuildManager.java
Made some bookeeping additions to the target so that it can store references
to tools. First, the target loads any tool references it has. Then it loads
tools and configurations. The target also has to consider the presence of tool
references when it determines how many tools it has, so the logic that counted
and returned the number of tools in the target was updated. Some key changes in
this regard relate to how the target looks up the tool references it has. It
now has to ask the managed build info if it has a tool definition for the reference
if there are no tools defined for the target level for a given reference.
* src/org/eclipse/cdt/managedbuilder/internal/core/Target.java
Tool references now have the potential to be owned by either a target or a
configuration. Changed the owner to the superclass of both and figure out
which the parent is at runtime to perform the proper registration and information
look-up. Also removed the reference to a target from a tool and the interface to
extract the target from ITool.
* src/org/eclipse/cdt/managedbuilder/core/ITool.java
* src/org/eclipse/cdt/managedbuilder/internal/core/Tool.java
* src/org/eclipse/cdt/managedbuilder/internal/core/ToolReference.java
An unrelated bug had to do with a problem my testing uncovered with nested
categories. The manifest reader was looking at the wrong field to determine
the parent, but for the manifests we have created, this has not proven to be
a problem so far.
* src/org/eclipse/cdt/managedbuilder/core/IOptionCategory.java
* src/org/eclipse/cdt/managedbuilder/core/IOptionCategory.java
the logic for managing the makefiles in the face of a header file
modification. There seems to be a problem (maybe with the dependency
calculation) for dependants in other projects when a header file is moved,
but other than that the builder seems to respond properly.
Two of the fixes, 43614 and 43756, involved changing property files only,
which validates the extra work of externalizing strings from the start!
For 43616, I simply took the advice of the bug reporter and added the '-'
in front of the RM macro in the clean target and the include directives in
the makefile.
The largest part of the fix involves 43220. Until just now, this was a
critical bug in bugzilla, so I addressed it. It has just been downgraded
to an enhancement request. There is now a new entry widget in the linker
options for user objects. The makefile will simply add these to the final
build target's command. Most of the work was done in the plugin file and
the build model to handle the new "type" of option.
the new project wizard now filters out targets that should
not be selected by the user, and that the build model
handles inherited option references properly now.
- I have removed the binary parser selection from the
new managed project wizard and hard-coded the proper
parser ID in the plugin spec for the build model. There is
an updated JUnit test that verifies this change to the
build model.
- There is also a fix for the library problem on *nix. The
makefile pattern was also changed slightly to better
capture the dependencies between the build target and
the outputs of other managed projects.
