1. Fix for [Bug 184449] [Template Engine] It should be possible to press "Finish" on the first wizard page for templates having default values assigned
2. Fix for [Bug 184593] [Template Engine] Need a way to add tool-chain associations to existing templates
3. Fix for [Bug 184455] [Template Engine] NPE in template engine tests
Part of the uncoming work to supply formatting in CDT
* schema/CodeFormatter.exsd
* src/org/eclipse/cdt/core/CodePreferenceConstants.java
* src/org/eclipse/cdt/core/ToolFactory.java
* src/org/eclipse/cdt/core/formatter/CodeFormatter.java
* src/org/eclipse/cdt/core/formatter/CodeFormatterConstants.java
* src/org/eclipse/cdt/internal/core/CCorePreferenceInitializer.java
* plugin.properties
* plugin.xml
- Since I forgot to do this last release, I am removing the
original managed build model schema and extension
points from the cdt core and ui projects.
This patch contains some minor UI changes and a big chunk of work to add
built-in symbols and includes search paths to a tool specification.
The UI change is a switch from dynamically resizing the property page when
an option category is selected from the list, but rather using a scrolled
edit area. Now, if the option set is larger than the viewable area, a
horizontal and/or vertical scrollbar is displayed.
In terms of built-ins, there is no UI support to change the values just
yet. That is coming, but I wanted to get the framework and some
definitions in place so that the indexer and scanner can start using them.
In order to work through CExtensionPoint mechanism, I have to change the
existing extension point entries for the Managed and Standard builders to
the following (all future builders will have to conform to this as well):
<extension
id="ManagedBuildManager"
point="org.eclipse.cdt.core.ScannerInfoProvider">
<cextension>
<run
class="org.eclipse.cdt.core.build.managed.ManagedBuildManager">
</run>
</cextension>
</extension>
<extension
id="StandardBuildManager"
point="org.eclipse.cdt.core.ScannerInfoProvider">
<cextension>
<run
class="org.eclipse.cdt.core.build.standard.StandardBuildManager">
</run>
</cextension>
</extension>
As well, the ManagedBuildManager and StandardBuildManager must extend
AbstractCExtension.
The new project wizards for managed and standard projects have to be
modified to register the right class as the scanner info providers for the
project. The example below shows the managed project wizard code, but the
standard project wizard is similar.
try {
ICDescriptor desc =
CCorePlugin.getDefault().getCProjectDescription(project);
desc.remove(CCorePlugin.BUILD_SCANNER_INFO_UNIQ_ID);
desc.create(CCorePlugin.BUILD_SCANNER_INFO_UNIQ_ID,
ManagedBuildManager.INTERFACE_IDENTITY);
} <snip>
Clients use a new method defined in CCorePlugin
public IScannerInfoProvider getScannerInfoProvider(IProject project) {
IScannerInfoProvider provider = null;
if (project != null) {
try {
ICDescriptor desc = (ICDescriptor)
getCProjectDescription(project);
ICExtensionReference[] extensions =
desc.get(BUILD_SCANNER_INFO_UNIQ_ID);
if (extensions.length > 0)
provider = (IScannerInfoProvider)
extensions[0].createExtension();
} catch (CoreException e) {
}
}
return provider;
}
to get the information provider as shown in the updated JUnit test code
below:
// Find the first IScannerInfoProvider that supplies build info for the
project
IScannerInfoProvider provider =
CCorePlugin.getDefault().getScannerInfoProvider(project);
assertNotNull(provider);
As is the case now, clients implement the IScannerInfoChangeListener
interface and pass themselves to the provider in a subscription message.
There is also a new method on the IScannerInfoProvider interface that
allows the client to get information immediately as shown below:
IScannerInfo currentSettings = provider.getScannerInformation(project);
The ManagedBuildManager::getScannerInfo(IResource) method will be
deprecated, then removed before the end of this release cycle.
I am in the process of documenting the build model and as I go along, a
number of things will have to be cleaned up in the actual model itself.
This patch is purely a bookeeping change to make it easier for me to
maintain the build model in the face of these changes as we go forward.
Where I used to access XML elements using hard-coded strings, I have moved
the string into the appropriate interface class. If the name of the
attribute changes in the future, I only have to update it one place.
I have also begun the process of renaming certain attributes of the schema
to make them better reflect what they are doing. My hope is that if they
have intuitive names, toolchain implementers will have less difficulty
understanding their intent. In any case, I have changed four attribute
names; optionRef -> optionReference, toolRef -> toolReference, optionValue
-> listOptionValue, and optionEnum -> enumeratedOptionValue.
Unfortunately, these changes will invalidate the dot-cdtbuild files for
any managed build projects in your workspace. If you can't bear to create
a new project, move the files over, and set-up the compiler options again,
you can always hand-edit the changes in the file yourself. Just remember
to restart CDT after you do so.
In order to meet certain internal guidelines and to test the makefile
generator, the build model replied to some answers with hard-coded
information. This patch moves the information into the build model. Tests
have been updated to reflect these changes, and the patch has been
smoke-tested on Unix.
- I added the ability to build when there are inter-project dependencies
(first iteration; I would like to try another way). There is also some
changes to how libraries are handled. Change logs describe the changes and
the AllBuildTests has been updated to reflect these changes.
The change logs contain an overview of what has been done to implement a new interface between a build model (any build model)
and clients of the model that need to extract include search paths and defined symbols. For the most part, I have tried to leave the
old build system as unchanged as possible. For example, project properties like the make search path, and whether or not to continue
on build failures are still stored as persistent properties on the project through the CNature (ugh). The new information I have added
is managed by a new build manager on a per-project basis and is associated with a project as a session property. The information is
persisted in the 'cdtbuild' file introduced by the new managed build system.
1. Fix for bug 38665 - Need to select platform before configurations become visible
2. Icon files that were not delivered in my last patch
3. A new interface for clients of the build model to extract include paths and defined symbols for managed projects. Unmanaged projects to follow soon.
Core
1. Added 2 new option types: Boolean and enumerated
2. Changed the IOption interface to get new option type values
3. In plugin manifest and IOption interface added concept of a default enumerated value to support on-going GUI work
4. In plugin manifest and IOption, added field to map the actual command line argument with the option for makefile generation.
Tests
1. Changed the plugin.xml manifest to match the new option types
2. AllBuildTests.java updated to test new option types and fields added in core
