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

[David Boyce]

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/