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.
