bugmake - Bugs: bug #30829, vpath conflict with file mention...

 
 

bug #30829: vpath conflict with file mention in makefile vs file on disk

Submitter:  None
Submitted:  Fri 20 Aug 2010 04:09:43 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  3.81 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 08 Jan 2023 07:44:51 PM UTC, comment #1: 

I checked this with GNU Make 4.4(.1) and see the same behavior still.  In the success case if we add -d and examine the output we get (extracting the interesting bits):

   Trying pattern rule '%.enu: %.h' with stem 'boo'.
   Trying implicit prerequisite 'boo.h'.
   Found prerequisite 'boo.h' as VPATH 'sue/boo.h'.
   Found implicit rule '%.enu: %.h' for 'boo.enu'.
    Considering target file 'boo.h'.
     Looking for an implicit rule for 'boo.h'.
     No implicit rule found for 'boo.h'.
     Finished prerequisites of target file 'boo.h'.
    No need to remake target 'boo.h'; using VPATH name 'sue/boo.h'.

We locate sue/boo.h via VPATH and it exists, and we don't have to remake it, so we succeed.

If we run in the failure case, we get this:

   Trying pattern rule '%.enu: %.h' with stem 'boo'.
   Trying implicit prerequisite 'boo.h'.
   Found prerequisite 'boo.h' as VPATH 'woo/boo.h'.
   Found implicit rule '%.enu: %.h' for 'boo.enu'.
    Considering target file 'woo/boo.h'.
     File 'woo/boo.h' does not exist.
     Looking for an implicit rule for 'woo/boo.h'.
     No implicit rule found for 'woo/boo.h'.
     Finished prerequisites of target file 'woo/boo.h'.
    Must remake target 'woo/boo.h'.

and we fail because we don't know how to create woo/boo.h.  Here we can see that we say we found woo/boo.h via VPATH, but in fact there is no file named woo/boo.h so it should not have been found.

It appears it was found because the mention of this file in this rule:

a.o: woo/boo.h

caused make to visualize it as a target that could be built, and so the vpath search finds it.

I'm not actually sure what if anything we should do about this.  I think it's intentional that make will check the set of targets that could be created for vpath matches.

Maybe we need to change things so that instead of giving up if we can't build a non-existing VPATH match, instead we try to find another vpath match for the file.

Paul D. Smith <psmith>
Group administrator
Fri 20 Aug 2010 04:09:43 PM UTC, original submission:  

Using 3.81
Perhaps this is garbage in garbage out:

Files:

$ ls woo sue
sue:
boo.h

woo:
$

Makefile:

$ cat vp.mk
a.o: woo/boo.h
# a.o: sue/boo.h

# succeed
# vpath %h sue woo
# fail
vpath %h woo sue


%.enu: %.h
        echo enu_BUILD_success $@ $<

all: boo.enu
        echo ALL success $@
$

when you run:

./gnumake.exe -f vp.mk all

gnumake finds woo/boo.h in vpath.c with the function selective_vpath_search (lookup_file line ~488).
It then does not check for the file on disk.

With

vpath %h sue woo

The lookup_file fails and the file is found with dir_file_exists_p.

The problem is the incorrect info:
a.o: woo/boo.h

I found the behaviour at first surprising.


Anonymous

 

(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 psmith (Updated 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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-27 psmith Item GroupNone Bug

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code