[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Feature Submission for GNU Make

From: Florian Rivoal
Subject: Re: New Feature Submission for GNU Make
Date: Tue, 31 May 2011 23:32:45 +0900
User-agent: Opera Mail/11.11 (MacIntel)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]