Apache OpenOffice (AOO) Bugzilla – Issue 73996
Don't generate relative paths up to the root directory
Last modified: 2013-08-07 15:34:52 UTC
Currently, when generating the target name of a prerequisite target using the .SETDIR attribute and the current target dmake creates a relative target paths. This is usually a good idea, but when the relative path goes up to the root directory and down into a different tree this might not be always the best idea. The same applies for the TMD macro. (For the native windows version there was always the absolute path used if the prerequisite lived on a different drive.) I'm actually not able to think of a problem for *nix systems with this practice, but when mixing a cygwin dmake with native W32 executables there are potential problems. For example the relative path from /home/user/ to /cygdrive/d/mydir/mytarget.bar would be ../../cygdrive/d/mydir/mytarget.bar . I don't see any harm in using the absolute path whenever the relative path would go up to the root directory for all OSs, it even slightly shortens the path, so that I wont make this patch cygwin specific.
Great, my example showed me that this approach is not enough to completely solve this problem. So far I only thought of pathes like this: ../../tmp/foo/bar.baz with mounted posix path components to produce problems, but there is also the /cygdrive/X/ case.
Created attachment 42561 [details] Patch for dmake
The previous patch has the desired behavior for "normal" *nix OSs plus it has some extra handling for the cygwin /cygdrive/X/ case. I verified that it works as expected with this makefile: --- makefile --- SHELL*:=/bin/sh SHELLFLAGS*:=-ce # The directory we started dmake in was /cygdrive/d/w1/something/ all: a1 @echo Making all with: $? #a1 .SETDIR=/tmp : #a1 .SETDIR=/cygdrive/d/temp : a1 .SETDIR=/cygdrive/c/temp : @echo Making a1 --- makefile --- I wont create a testcase as that would depend on the path the testsuite is executed in. Commited to dmake48.
This works well and dmake48 is finished.
c