Re: Order of expansion of recipe lines

On 14 March 2016 at 14:22, Paul Smith wrote: > 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) > > or in

Re: Order of expansion of recipe lines

On Mon, 2016-03-14 at 11:55 -0700, Zoltan wrote: > > I was looking through the parsing code a week ago. As of 4.1 it treats ${ > > and > > $( as meaning exactly the same thing. In our build we use the convention > > $() > > for macro calls and ${} for variable expansions, but the opposite could

Re: Order of expansion of recipe lines

On 03/14/2016 11:55 AM, Paul Smith wrote: > include my.mk > > my.mk: ; @echo '$$(OBJDIR)/foo.o: foo.c' > $@ > > > And are you suggesting that we would treat $$(foo) differently than > $$foo or $${foo} when expanding recipes? > >> For cases of recipe lines that do not have a '$(' construct,

Re: Order of expansion of recipe lines

On Mon, 2016-03-14 at 11:07 -0700, Zoltan wrote: > Not exactly escaping '$' with '$$'. From your example of $(info ...), I'm > actually suggesting to escape '$(' with '$$('. So not quite the same thing at > all. And this is already implemented, and already "explained," so no extra > work there.

Re: Order of expansion of recipe lines

On 03/14/2016 11:10 AM, Brian Vandenberg wrote: > For cases of recipe lines that do not have a '$(' construct, would there > actually be any difference at all, whether or not you change the expansion > style? I can't think of one...or maybe its just I can't think...at any > rate, >

Re: Order of expansion of recipe lines

> > As you say, done simply this would be a major backward-incompatibility > and very complicated to explain as well. To avoid the backward > -incompatibility we'd need to do some kind of semi-evaluation that only > processed functions we know (a) might have side-effects, and (b) will > expand to

Re: Next release of GNU make coming soon

> > If you have things you'd like to see addressed that you haven't gotten > around to sending or adding to Savannah, now would be the time to do > that. I would appreciate it if the patch I submitted for bug 46443 could get evaluated for inclusion. -brian ___

Re: Order of expansion of recipe lines

On Mon, 2016-03-14 at 10:36 -0700, Zoltan wrote: > I don't particularly see a reason to change current behavior, but if > you want to, how about implementing it like a "delayed" expansion > except for recipe lines, so instead of $(...whatever), it would > be written $$(...whatever...) in ord

[bug #47409] API support for accessing build internals

Follow-up Comment #1, bug #47409 (project make): w/regard to build introspection: this could be useful for doing something like the following. Admittedly it's a contrived example, but I've had ideas along these lines (but less contrived) that it would help with: TARGETS := ... some stuff here ..

Re: Order of expansion of recipe lines

On Mon, 2016-03-14 at 10:24 -0600, Brian Vandenberg wrote: > This could be remedied by making it fork before recipe expansion so > the expansion happened in a sub-process. On the plus side it > eliminates concerns of macros slowing down the parent make process > but it breaks backward compatibilit

[bug #46995] Within 'define' newline is treated as non whitespace

Follow-up Comment #1, bug #46995 (project make): I don't know whether they'll want to fix this, but this is the pattern I use for situations like that: define SOMETHING = $(foreach variable, list of values , expression ) endef I would prefer leading commas as in: define SOMETHING = $(foreac

Re: Order of expansion of recipe lines

On 03/14/2016 10:59 AM, Paul Smith wrote: > On Mon, 2016-03-14 at 10:36 -0700, Zoltan wrote: >> I don't particularly see a reason to change current behavior, but if >> you want to, how about implementing it like a "delayed" expansion >> except for recipe lines, so instead of $(...whatever), i

Re: Next release of GNU make coming soon

> > The autotools version only impacts people who want to build from Git. > If you are building from a release tarball it shouldn't matter what > version of autotools was used to create the release tarball. > Good point; in that case I don't have a preference. Is there some Solaris build system w

Re: Order of expansion of recipe lines

On 03/14/2016 07:22 AM, Paul Smith wrote: > 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 w

[bug #47409] API support for accessing build internals

URL: Summary: API support for accessing build internals Project: make Submitted by: phantal Submitted on: Mon 14 Mar 2016 05:33:25 PM GMT Severity: 3 - Normal Item Group:

Re: Next release of GNU make coming soon

On Mon, 2016-03-14 at 10:50 -0600, Brian Vandenberg wrote: > In Solaris it can sometimes be painful to get newer versions of auto > -tools. At a minimum, please double-check OpenCSW to make sure the > version you switch to is at least equal to if not lower than the > latest version they have build

Re: Next release of GNU make coming soon

> > I've been thinking about updating the autotools prerequisites in the GNU > make build system to newer versions; that would include autoconf, > automake, and gettext. > > I'm most interested in gettext as the version we're using now (0.18.4) > has some old/deprecated autoconf m4 macros that woul

Re: Order of expansion of recipe lines

My apologies if this ends up being a double-post. I've gotten used to the fact that expansion occurs before recipe invocation, but I'll lay out some of my thoughts on this. Currently, expansion occurs in the parent process before it fork()s. One of the things I was doing in the build looked

Re: Order of expansion of recipe lines

I've gotten used to the fact that expansion occurs before recipe invocation, but I'll lay out some of my thoughts on this. Currently, expansion occurs in the parent process before it fork()s. One of the things I was doing in the build looked something like this: .RECIPEPREFIX := > target :

Re: Order of expansion of recipe lines

On 14 March 2016 at 14:22, Paul Smith wrote: > > > 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. > > I dunno

Order of expansion of recipe lines

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 e

[bug #45728] .VARIABLES not updated after undefine

Follow-up Comment #4, bug #45728 (project make): Typo. I fixed it last night in my local repo but haven't pushed that yet. It shouldn't matter. ___ Reply to this item at: _

[bug #45728] .VARIABLES not updated after undefine

Follow-up Comment #3, bug #45728 (project make): Why do the two variables have different types? +static unsigned int variable_changenum; + static unsigned long last_changenum = 0; ___ Reply to this item at: