| RE: [cdt-dev] Migrating MBS to Eclipse 3.3: changes in Path behav ior |
|
Having said that, the fact that you have
to use ./ to tell the shells to execute something in the current directory when
. is not in your path is similar and the new Path behavior would break that
too. I’m just thinking that our use of it is a little less obvious than
that. Not to mention that this is a behavior
change to Path, which at this point of the game, why???? Doug Schaefer, QNX Software Systems From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer It sounds like a pretty bad assumption.
Semantically, the two “./blah” and “blah” are the same,
we shouldn’t be expecting the frameworks to maintain the syntactic
difference. And relying on that is really unmaintainable code. If you
hadn’t have told me that, I (or someone else) would have probably broke
it. Is there some other mechanism we can put in place to make this work that’s
a bit more obvious? Doug Schaefer, QNX Software Systems From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail 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 |