From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Friday, May 25, 2007 2:29 PM
To: CDT General developers list.
Subject: [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