| [cdt-dev] Migrating MBS to Eclipse 3.3: changes in Path behavior |
|
Hi all, I was testing the Managed Build functionality and
found quite an interesting regression caused by the changes in the behavior of
the org.eclipse.core.runtime.Path. Just wanted to share this problem with all since I
guess that there might be some integrations that would face the issue. The changes in the Path I observed is that with the
3.2.2 the Path(String) constructor and also Path.from*String() methods generate
the “./some/path” path given a “./some/path” string With the 3.3 the above generate “some/path”
for the same string (note the “./” stripped) Historically MBS
contains some logic that behaves differently depending on whether the “./”
is prefixed or not, e.g. org.eclipse.cdt.managedbuilder.core.IManagedOutputNameProvider
is expected to return a one-segment path to force path to be prepended by the
build output [sub]directory path, so returning “./foo.o” and “foo.o”
would have different meaning and behavior, i.e. the “./foo.o” would
force the foo.o to be located in the root output directory, while “foo.o”
would result in putting the foo.o in the output_dir/source/relative/directory/foo.o
There was some code in MBS relying on the 3.2 Path
behavior, e.g. something like path = Path.fromOSString(“./” + name
+ extension); Stripping the “./” in eclipse 3.3 resulted in incorrect
output calculation for the case the tool wanted to force the output to be
located in the build output root directory for. The only way that I have found to preserve the “./”
is to use path = new Path(“./”).append(name + extension) instead. The Build System code is now changed to use the latter
variant. Please check your code relying on the “./” to be prepended. I guess this is worth adding to the MBS 3.x to 4.0 migration
guide I’m working on currently. An other thing I’m worried about is that the
future Path “enhancements” might not allow having the “./”-prefixed
paths at all. Thoughts? Regards, Mikhail |