On Fri, Feb 08, 2019 at 04:07:08PM -0500, Paul Smith wrote:
> On Fri, 2019-02-08 at 14:32 -0500, Mike Haboustak wrote:
> > It seems that the value of $< is getting defaulted for implicit rules
> > during second expansion. However, the value of $< is correct in the
> > recipe.
> >
> > If this is the expected behavior, is there a way I can use secondary
> > expansion with implicit rules and get the correct value of $< for
> > foo.o (foo.c)?
>
> I can't remember the complexity around expanding $< for implicit rules;
> it's something to do with when the expansion happens during pattern
> matching.
>
> However, for a workaround you can use $$*.c instead of $$< in this
> situation and get the same result.
>
It seems in this case, $$*.c returns ".c", as the star variable is
empty. Building on the previous makefile:
foo.o: foo.c $$(info in foo.o\: $$$$< = $$< and $$$$^ = $$^ $$$$*.c = $$*.c)
in foo.o: $< = foo.o and $^ = baz.c $*.c = .c
I was hoping for a more generalizable solution. My ultimate goal is to
trigger the rebuild of a target when conditions beyond timestamp change.
Similar to the if_changed functionality from kbuild, but using conditional
prerequisites rather than conditional recipes. My intent is to emit a
phony prerequisite during second expansion that can trigger a rebuild.
If I am able to do this, then I can cleanly separate the logic of
building the target from evaluating whether the target is up-to-date.
Unfortunately, this requires the automatic file variables to be consistent
between second expansion and the recipe.
I'm interested in looking further into this issue and trying to find a
solution. Do you think that it's worth putting effort into it? Or should
I just follow kbuild's example and implement this in the recipe?
_______________________________________________
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-make
