Re: [bug #55137] $(file …) is executed too early when used in recipe

[Paul Smith]

I'm publishing this back to the list as I don't like to have private
conversations on these subjects; hopefully you don't mind.

On Wed, 2019-05-15 at 11:19 -0800, Britton Kerin wrote:
> I agree that having file behave differently would be weird, but it
> does seem like it would be nice if make functions were expanded a
> command at a time (rather than a recipe at a time).  It would be too
> breaking as a general change but perhaps as a .DIRECTIVE: ?

There's no question whatsoever that this behavior has bitten many
people, many times.  It's one of the more common questions on
StackOverflow, etc.

I'm honestly not sure why expansion is done that way (it predates my
involvement in GNU make maintenance).  Offhand it seems like an
arbitrary choice: I can't think of a good reason for it.  Maybe someone
else can point out a use for it.

I wonder how much code would actually break by just changing it. 
Certainly, any such code would have to be written in a weird way
although obviously "weird code" does exist.

For example someone could write something like:

   foo:
           @cat somefile
           $(shell echo foo > somefile)

which would break if we started delaying expansion until the recipe
line was being invoked.  But who's going to write that?

The only idea I have for "legitimate real-world use" is something like:

    foo:
            do some things
            $(DO-MORE)

where DO-MORE is some boilerplate macro defined elsewhere, that wants
to perform some checking and invoke $(error ...) if badness is
detected.  It might be relying on the entire recipe being expanded up-
front to do that error checking before any part of the recipe is
invoked.

I just really hate lots of tweakable options: you get an exponential
increase in testing requirements etc.