On Tue, 31 May 2011 20:57:10 +0900, Edward Welbourne <[email protected]>
wrote:
I haven't looked at the code, but one warning: it's important to not
assume that blah/../foo/ is equivalent to foo/ - blah might be a
symlink.
While this is true, I am not sure one which side this should be solved.
Simply not treating blah/../foo/ as equivalent to foo/ would greatly
reduce what the proposed patch can do. Assuming good documentation, would
it be unreasonable to expect the user of GNU make to know what he is
doing, and to avoid using the functions as they are proposed if their
build tree contains directory symlinks?
If we want to solve this in the proposed functions, assuming blah is a
symlink to some/other/path, $(trimpath blah/../foo/) should return
some/other/foo/.
But if we want to let the user decide, we can keep trimpath as it is, and
introduce resolve-symlinks, so that $(trimpath $(resolve-symlinks
blah/../foo/)) can be used to get some/other/foo/, while $(trimpath
blah/../foo/) can be used to get foo/
If you do have a tree that contains symlinks to directories, I can't
really imagine a situation where you wouldn't want the symlink resolution.
But then again I am sure my imagination has limits.
As for trees that don't have symlinks to directories, the only benefit of
the current implementation (without symlink resolution) would be
performance, as you don't have to query the file system.
I am inclined to think that given that overhead of symlink resolution
would be fairly low in absolute terms, and that there appears to be no
valid uses of trimpath without symlink resolution on trees that do contain
symlinks, trimpath would benefit from being rewritten to resolve symlinks,
but I wouldn't be surprised to be proven wrong on either of my assumptions.
- Florian
_______________________________________________
Bug-make mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
