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,
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,
>
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 recip
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
On 02/16/2016 12:34 PM, Manoj Srivastava wrote:
> but POSIX sayeth
>
> | An execution line is built from the command line by removing
> | any prefix characters. Except as described under the at-sign
> | prefix, the execution line shall be written to the standard
> | output, optionally preceded b
On 02/16/2016 12:34 PM, Manoj Srivastava wrote:
> but POSIX sayeth
>
> | An execution line is built from the command line by removing
> | any prefix characters. Except as described under the at-sign
> | prefix, the execution line shall be written to the standard
> | output, optionally preceded b
keep this small, sane, and yet usable in the most common
situations. Its not intended to provide a transactional database locking
mechanism...
Any thoughts, suggestions, or pointers (especially to where in the make source
tree I should begin with...) are appreciated.
Thanks,
Zoltan
--
##
