bugmake - Bugs: bug #62232, could targetshave an implicit...

 
 

bug #62232: could targetshave an implicit order-only dependency on their parent directory?

Submitter:  David Boyce <boyski>
Submitted:  Tue 29 Mar 2022 01:37:57 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  None Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 29 Mar 2022 01:37:57 PM UTC, original submission:  

Just floating a thought ballon here, having to do with targets that go into directory structures needing to be created on the fly. The first attached example (Makefile.bad) illustrates the basic newbie problem:

$ make -f Makefile.bad
touch foo.d/bar.o
touch: cannot touch `foo.d/bar.o': No such file or directory
make: * [Makefile.bad:8: foo.d/bar.o] Error 1

The parent dir doesn't exist so the recipe fails. In my organization we've solved this by establishing a pattern illustrated by the second attachment (Makefile):

$ make
mkdir -p foo.d
touch foo.d/bar.o

Each target is given an order-only dependency on its parent with help from .SECONDEXPANSION. This works very nicely, with the aid of a macro or two not shown here, and I recommend it as a pattern. However, it does require some discipline and typing; users must remember to append the magic string "| $$(@D)" to every target, provide a mkdir rule, etc.

It occurs to me that the core of the original problem is that the missing dir isn't discovered until recipe time; note that the error message above comes from a shell command.

So my question is, why shouldn't make targets have an implicit O-O dependency on their parent dirs? It would simplify the real-life use case shown in Makefile, not to mention that reporting errors as early as possible is generally a good thing.

Consider the third attachment (Makefile.demo) which differs from Makefile.bad only in having the O-O dependency spelled out:

$ make -f Makefile.demo
make: * No rule to make target 'foo.d', needed by 'foo.d/bar.o'.  Stop.

Here the problem is exposed by make without needing to run the recipe. If make worked like this by default life would be simpler.

The obvious counter-argument is that it's quite common to embed a mkdir in the recipe:

foo/bar:
        mkdir -p $(@D)
        touch $@

This, IMHO, is the wrong way to do things but it's ubiquitous and must be supported so my proposal would presumably require a special target. But in an ideal world I think $@ always having an implicit O-O dependency on $(@D) would be a good thing.

David Boyce <boyski>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #53022:  Makefile added by boyski (222B - application/octet-stream)
file #53020:  Makefile.bad added by boyski (126B - application/octet-stream)
file #53021:  Makefile.demo added by boyski (177B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by boyski (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-29 boyski Attached File- Added Makefile.demo, #53021
        Attached File- Added Makefile, #53022
    2022-03-29 boyski Attached File- Added Makefile.bad, #53020

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code