> Path has not changed
recently. This behavior was in 3.2.1,
I’ve just tested the following
code against eclipse 3.2.2 and 3.3 on my Win-XP machine:
IPath path = new Path("./MODULE.mod");
IPath osPath = Path.fromOSString("./MODULE.mod");
Both constructions create
two-segment paths "./MODULE.mod" in 3.2.2 and one-segment path "MODULE.mod" in 3.3
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Keith Campbell
Sent: Wednesday, May 30, 2007 6:03
PM
To: CDT
General developers list.
Subject: 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
