Something that seems to be a constant source of confusion for users is
the fact that GNU make expands the entire recipe first, before it starts
any rules. Consider this recipe:
all:
@echo hi
@$(info there)
You would expect to see:
hi
there
but in reality, since make expands all lines of the recipe first before
starting any rules, you actually see this:
there
hi
In the early days of GNU make where functions didn't really have side
-effects (except for $(shell ...) which doesn't make much sense to use
in a recipe anyway) it was very hard to notice this ordering. But now,
as we've added many more functions with side effects (not just info, but
also eval, file, etc.), it's not hard to get surprising results.
I wonder if we shouldn't change the way we handle expansion of recipe
lines to meet peoples' expectations: instead of expanding all recipe
lines first we would expand recipe lines one at a time, as we got ready
to run that line.
It would be a backward-incompatible change, although the fix is easy
enough (just be sure you put everything you want to be expanded first in
the first line of the recipe). Still it's a change, which can involve a
lot of work for people if they were scattering things around their
recipe lines but expecting them to be expanded first.
Is there a real advantage to the current behavior? The only one I can
see is if you broke your recipe down into variables that were used in
multiple lines, and expected to be able to use this "expand first" to
have things happen before the first line was invoked.
Something like this:
FOO :=
LINE1 = $(eval FOO += bar
LINE2 = $(eval FOO += baz)
all:
@echo $$FOO
@$(LINE1)
@$(LINE2)
With today's behavior you'd get "bar baz" printed; with the new behavior
you'd get "" printed. Clearly this exact thing is not useful but I
guess I could envision uses: maybe the different LINE variables are
defined in different makefiles and combined in different recipes in
different ways, or something.
I dunno. Opinions?
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
