[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #55137] $(file …) is executed too early when used in recipe
From: |
Britton Kerin |
Subject: |
Re: [bug #55137] $(file …) is executed too early when used in recipe |
Date: |
Thu, 16 May 2019 14:54:25 -0800 |
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