bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pattern rules and '/'


From: Frank Heckenbach
Subject: Pattern rules and '/'
Date: Mon, 27 Feb 2023 16:52:55 +0100

GNU Make 4.4.1

According to the manual, in pattern rules, "the '%' matches any
nonempty substring". Accordingly, I'd have expected this Makefile:

  all: foo-bar/baz
  foo-%:; echo "$*"

to echo "bar/baz". But instead, I get:

  make: *** No rule to make target 'foo-bar/baz', needed by 'all'.  Stop.

After some further reading, I found this:

  When the target pattern does not contain a slash (and it usually
  does not), directory names in the file names are removed from the
  file name before it is compared with the target prefix and suffix.
  After the comparison of the file name to the target pattern, the
  directory names, along with the slash that ends them, are added on
  to the prerequisite file names generated from the pattern rule's
  prerequisite patterns and the file name. [...] Thus, 'e%t' matches
  the file name src/eat, with 'src/a' as the stem.

That seems rather strange to me (in which case would you want
"src/a"?), and IMHO contradicts the first statement quoted above,
and that's apparently the reason for my problem.

My actual use case is something like this (greatly simplified):

  DIRS = foo bar baz
  all: $(addprefix recurse-, $(DIRS))
  recurse-%:; $(MAKE) -C "$*"

This has worked well for a long time while I had only single-level
subdirectories. Now that I added some second-level subdirectories,
it broke with the message above.

Now, it seems I can work-around this problem using suffixes instead
of prefixes, like this:

  DIRS = foo bar baz foo/qux
  all: $(addsuffix -recurse, $(DIRS))
  %-recurse:; $(MAKE) -C "$*"

But before I start making those changes (I have a number of those
rules in various Makefiles, so it'll be a bit of work), I'd like to
clarify:

- Is this actually the expected behaviour of make, not a bug?

- What is it useful for?

- Will using suffixes avoid the problem reliably, or are there any
  other pitfalls to be aware of?

- Can you please point out this problem in the manual more clearly
  (like at the first quote above)? As is it, it reads like a lot of
  commercials, making a big promise first and in the fine print
  (on another page), adding limitations. If I'd known this before,
  I could have used suffixes from the start and avoided that extra
  work now.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]