Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Migrating MBS to Eclipse 3.3: changes in Path behav ior


Path has not changed recently. This behavior was in 3.2.1, but if you ask me it should never have made assumptions about the meaning of segments with the names '.' or '..'.

-Keith



Doug Schaefer <DSchaefer@xxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

2007/05/25 14:43

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject
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
Eclipse CDT Project Lead,
http://cdtdoug.blogspot.com



From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent:
Friday, May 25, 2007 2:38 PM
To:
CDT General developers list.
Subject:
RE: [cdt-dev] Migrating MBS to Eclipse 3.3: changes in Path behav ior

 
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
Eclipse CDT Project Lead,
http://cdtdoug.blogspot.com



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_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top