bugmake - Bugs: bug #15338, make: stripping leading ./ causes...

 
 

bug #15338: make: stripping leading ./ causes flaky results

Submitter:  Manoj Srivastava <srivasta>
Submitted:  Sat 31 Dec 2005 03:33:43 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Duplicate Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 03 Jul 2010 07:51:57 PM UTC, comment #1: 

I can no longer reproduce this with the latest CVS code.  If you still see it with the next release of GNU make please comment here and we can re-open the bug.

Paul D. Smith <psmith>
Group administrator
Sat 31 Dec 2005 03:33:43 PM UTC, original submission:  

make is doing something funny in the area of stripping the leading ./ from filenames.  I can demonstrate with the following Makefile, which is also attached so you get a copy without whitespace damage.

    files := $(shell find . -type f -print)
    objects: $(addprefix ./, $(files))
    install: $(addprefix /home/andrew/, $(files))
    $(addprefix /home/andrew/, $(files)): /home/andrew/%: ./%
            true $<

Put this in an empty directory, then create some files, eg

    for i in $(seq 1 10); do touch foo$i; done

and run

    make install

Output:

    true foo1
    true foo2
    true foo3
    true foo4
    true ./foo5
    true foo6
    true foo7
    true foo8
    true ./foo9
    true foo10
    true Makefile

Funny, huh?  I gave a little attempt to tracking it down.  I thought maybe parse_file_seq was at fault, but it seems to give correct results. Then, I looked at the output of

    make -r -p install

Looking at the \"Not a target\" entries, I see foo5, ./foo5, and foo4, but no ./foo4.  So it seems that for some reason foo5 has an entry under both names and they are aliased in some way.  I can\'t imagine why this only afflicts some files.

Also, I noticed that if I comment out the second line of the Makefiles (which defines the unused objects target), the output is:

    true ./foo1
    true ./foo2
    true ./foo3
    true ./foo4
    true ./foo5
    true ./foo6
    true ./foo7
    true ./foo8
    true ./foo9
    true ./foo10
    true ./Makefile

This seems to be a mostly cosmetic bug, but the aliasing is somewhat worrying.

Manoj Srivastava <srivasta>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #2292:  makefile added by srivasta (194B - application/octet-stream - attached makefile)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by srivasta (So that the Debian BTS may track progress on this)
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-03 psmith StatusNone Duplicate
        Open/ClosedOpen Closed
        Component VersionNone 3.81
    2006-03-20 srivasta Carbon-Copy- Added -email is unavailable-
    2005-12-31 srivasta Attached File- Added makefile, #3233

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code