bugmake - Bugs: bug #42690, make unconditionally resolves the...

 
 

bug #42690: make unconditionally resolves the current directory

Submitted by:  None
Submitted on:  Sat 05 Jul 2014 07:57:46 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: Not A BugPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: NoneOperating System: None
Fixed Release: NoneTriage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 07 Jul 2014 05:01:58 AM UTC, comment #2:

The problem is make cannot find out what the path you used was. Before make is started, the "cd" will resolve the symbolic link and when make starts and determines what its working directory is, that directory will be the final destination. Symbolic links are one-way: there is no way to "go back" through the link. Programs cannot tell how you got to the working directory, they only know where there are now and they only know the real path of that directory.

Only the parent shell, where the "cd" ran, can know that you used a symbolic link to get where you are, rather than the "real" path. Some shells will set an environment variable, like "PWD", that contains the "virtual" path. Some do not. Sometimes that variable will be exported so that programs like make can see it. Other times not. It's not reliable, so make does not use it. However, if your shell does support this then you can use it yourself since all environment variables are imported into make as make variables. Of course if someone uses your makefile and they do not use a shell that supports this, then they won't be able to take advantage of it.

Paul D. Smith <psmith>
Project Administrator
Sat 05 Jul 2014 08:05:22 PM UTC, comment #1:
Christopher Yeleighton <yecril71pl>
Sat 05 Jul 2014 07:57:46 PM UTC, original submission:

{ cd /tmp && mkdir a && ln -sT a b && cd b && make -w; }

make: Entering directory `/tmp/a'

Why not /tmp/b? Is there an option to prevent this resolution?
I understand that relative path names must be resolved;
but could you leave directory aliases as they are please?

This hit me when I tried to make in a directory that had a colon in the name;
this caused targets containing $(CURDIR) to be split and resulted in an error;
I made a symbolic link to avoid the path with colon but it did not work;
make decided it would rather use the original path instead.

And, last but not least, this behaviour is undocumented
(at least in the info file).

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by yecril71pl (Posted a comment)
  • -unavailable- added by yecril71pl (Voted in favor of this item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 07 Jul 2014 05:01:58 AM UTCpsmithStatusNone=>Not A Bug
      Open/ClosedOpen=>Closed
    Sat 05 Jul 2014 08:05:22 PM UTCyecril71plCarbon-Copy-=>Added yecril71pl

    Back to the top


    Powered by Savane 3.1-cleanup1