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

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #45763] Split args along MAX_ARG_STRLEN for linux/posix

[Dan Kegel]

Follow-up Comment #2, bug #45763 (project make):

1) the patch could do with a test.  

2) grpc hits a similar problem, see https://github.com/grpc/grpc/issues/14844

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make