Follow-up Comment #4, bug #62206 (project make):
Such a workaround with 2 rules could be something like
.SECONDEXPANSION:
all: lib/hello.o hello.o
%.o: 3$$*.c; $(info $@ from $<)
lib/%.o: lib/3$$*.c; $(info $@ from $<)
___
Ambrus Sumegi (21 March 2022 14:22) wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call to
> the sub-make ends without having to parse a shell command. So, when
> running with the -n switch, it can simply
Follow-up Comment #3, bug #62206 (project make):
> What I usually do is recommend people use $$* instead of % in secondary
expansion expressions like this as it's more clear and less confusing, and
ends up being the same result.
There are situations where the difference between % and $$*
If the invocation is a function, i.e., `$(make,"external_target") | tee
logs/external_task.log` then Make knows exactly where the call to the sub-make
ends without having to parse a shell command. So, when running with the -n
switch, it can simply print "make external_target | tee
(We generally prefer to use inline replies on the GNU lists, rather
than top-posted replies, thanks)
On Mon, 2022-03-21 at 13:22 +, Ambrus Sumegi wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call
On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote:
> For the record, I’ve thought of a sort-of-solution to the “would you
> have Make parse the shell command” question over the weekend. If the
> sub-make was called through a function rather than a variable, the
> whole issue could be a lot
For the record, I've thought of a sort-of-solution to the "would you have Make
parse the shell command" question over the weekend. If the sub-make was called
through a function rather than a variable, the whole issue could be a lot more
contained. Having $(make, "") as the canonical
form of
Follow-up Comment #2, bug #62206 (project make):
What I usually do is recommend people use $$* instead of % in secondary
expansion expressions like this as it's more clear and less confusing, and
ends up being the same result.
I'll look at this change.
