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

[Britton Kerin]

On Thu, May 16, 2019 at 7:37 AM Paul Smith <address@hidden> wrote:
>
> 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.

I don't know for sure, but I can testify that I've used make pretty
extensively for many years, including many of the less usual features
(static pattern, order-only rules etc.) and I only recently learned
about this peculiarity.  Not sure if that means my code is insensitive
to it or unconsciously dependent in some way.

> 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.

Sadly true.  I'll test rat on my stuff if you want to try it as a
flat-out change, but tbh it strikes me as a bit risky that way.

Britton