bugmake - Bugs: bug #42270, Make needs to canonicalise paths

 
 

bug #42270: Make needs to canonicalise paths

Submitter:  Robert Bogomip <bobbogo>
Submitted:  Fri 02 May 2014 09:39:02 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.0 Operating System:  Any
Fixed Release:  None Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 01 Sep 2023 03:52:28 AM UTC, comment #2: 

The bug wasn't opened by someone looking to have symlinks resolved, but that's what will happen if you canonicalize paths.

Applications must assume that symbolic links belong to the user and not expand them, unless somehow explicitly requested.

Applications that canonicalize path names and expand symbolic links do wrong, annoying things, such as put files into the wrong directories.

Suppose we have a file

  src/parser.c -> ../../foo-project/src/parser.c

When we build parser.c we want parser.o to be right here based on editing src/parser.c to src/parser.o.

Suppose the build system canonicalizes the path, turning src/parser.c into /home/bob/foo-project/src/parser.c. And then calculates the .o file from that? We end up with the object file going to  ../../foo-project/src/parser.o where we don't want it.

Symbolic links are something *the user set up to fool the application*.

Applications should cooperate and *stay fooled*.

I think the right position in Make is that if the user has used symbolic links (or any other path mechanism like ".." and "." links or absolute versus relative) such that they refer to the same file using two different paths, that's their problem; it's pretty easy to avoid, and avoiding that will almost certainly improve the clarity of the Makefile.

GNU Make has all the tools: it has $(realpath ...) and $(abspath ...); it's up to the Makefile programmer to decide whether either of these should be used and how, and avoid situations when accessing the same thing using two or more paths causes a problem.

Kaz Kylheku <kkylheku>
Mon 08 Sep 2014 12:48:48 AM UTC, comment #1: 

Every version of make I've ever encountered has always worked this way: they all use string comparison to match up prerequisite and target names, not some intrinsic of the operating system (absolute path, device/inode number, etc.)  I've checked the POSIX spec and it seems to imply this behavior although I don't see a specific requirement.

In any event, a change like this will need a lot of thought and consideration of possible ramifications.  For example, what about files which are symbolic links to each other?  Should make be able to determine that?  Using absolute paths may or may not be able to tell the difference, depending on the algorithm used to compute the absolute path.  What about a file with two different paths hard-linked?

In your example you use $(abspath ...) but that's not necessarily always correct.  Also, how would something like this interact with VPATH?  It's obviously wrong to apply $(abspath ...) to targets that make is intended to locate via VPATH lookup.

Paul D. Smith <psmith>
Group administrator
Fri 02 May 2014 09:39:02 PM UTC, original submission:  

Consider this makefile:


all:

abs := $(abspath AA)

${abs}: ; touch $@ # 1
AA: ; touch $@ #2

all: AA ${abs} ; : $@ done


We get


$ rm -f AA; make -Rr -f 1 -j
touch AA #2
touch /cygdrive/g/Code/x-platform/trunk/build/xplatform/AA # 1
: all done


Plainly AA and $(abspath AA) are the same file, but make doesn't think so. Make seems just to use string matching (other relative paths to the same file are seen as different files (_subdir/../A.. for instance)).

This is playing havoc with auto-generated dependencies, some of which are built by make rules.

Tested on SuSE make 3.82 and cygwin 4.0.

Robert Bogomip <bobbogo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kkylheku (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by bobbogo (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-08 psmith Item GroupBug Enhancement
        Triage StatusNone Medium Effort

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code