Re: New Feature Submission for GNU Make

[Florian Rivoal]

On Tue, 31 May 2011 20:57:10 +0900, Edward Welbourne <address@hidden>  
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