URL:
<https://savannah.gnu.org/bugs/?62232>
Summary: could targetshave an implicit order-only dependency
on their parent directory?
Project: make
Submitted by: boyski
Submitted on: 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
Discussion Lock: Any
Component Version: None
Operating System: Any
Fixed Release: None
Triage Status: None
_______________________________________________________
Details:
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.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Tue 29 Mar 2022 01:37:58 PM UTC Name: Makefile Size: 222B By: boyski
<http://savannah.gnu.org/bugs/download.php?file_id=53022>
-------------------------------------------------------
Date: Tue 29 Mar 2022 01:37:57 PM UTC Name: Makefile.bad Size: 126B By:
boyski
<http://savannah.gnu.org/bugs/download.php?file_id=53020>
-------------------------------------------------------
Date: Tue 29 Mar 2022 01:37:57 PM UTC Name: Makefile.demo Size: 177B By:
boyski
<http://savannah.gnu.org/bugs/download.php?file_id=53021>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62232>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
