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
ui.tests/src/org.eclipse.cdt.testplugin
packages to org.eclipse.cdt.core.testplugin and org.eclipse.cdt.ui.testplugin respectively.
This fixes a problem where the tests were incorrectly loading the wrong test plugin class.
- assert project create/deletion failure with detailed messages
- use common (were possible) project create/deletion methods in CProjectHelper.
- fixed problem with dep test when generating code the file was never closed causing project deletion to fail on win32
- upgrade plugin.xml files
- use PDE containers
- apply Eclipse 3.0 porting items, in particular openEditor and gotoMarker
- remove TestWorkbenches from test plugins
Bug 43450 - Path strings containing backslashes need quoting by hand
The user needs to input strings in whatever manner necessary for their
build tools to work. If that means quoting them, then quote them.
However, if the user does quote them, then the scanner needs to handle
that when looking for include files:
core:
-modify Scanner.handleInclusion
core.tests:
- added testBug43450 to ManagedBuildTests.java
- added a user include to plugin.xml
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.
This patch adds a "hook" for F1 help on the new managed project wizard
configuration selection page. It also adds functionality to the managed
build project property page to allow the user to edit the make command and
build artifact name. They can also add and delete configurations from a
target. There is no support for adding another target to a project in this
release.
- 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.
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.
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.
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.
Unit tests of code in the Core plugin should now be placed in the core.tests plugin.
(I did not delete test from the ui.tests plugin, but that's an idea whose time is coming soon.)
Resources and property files for unit tests are now in a separate directory from the root.
The testlauncher may experience some turbulence, but out of the box tests work as before.
