> > I'm not sure though if this is intended behavior or just a bug
> Well, actually I am using version 4.1 and I do see the difference, are
> you sure it is not working as intended ?
Well, as I said above, I'm definitely not sure. I would most likely consider it
being a bug.
Nevertheless, it's a
The GNU R project provides a toolchain (gcc 4.9.3 / mingw-w64) with
utils in a bundle called Rtools [1] for Windows users to compile
contributed packages
The current Rtools includes make 3.79.1. We are trying to upgrade to a
newer version, however the behavior of 'make' seems to have changed in
a
> From: Jeroen Ooms
> Date: Tue, 20 Sep 2016 15:24:49 +0200
>
> The current Rtools includes make 3.79.1. We are trying to upgrade to a
> newer version, however the behavior of 'make' seems to have changed in
> a way that breaks our infrastructure.
It has changed, allright, but the change wasn't
"Warlich, Christof" writes:
>> There is no difference between the two. They both declare environment
>> variables for make.
>
> That's not entirely true, at least not for (admittedly rather ancient) GNU
> Make V3.81.
> E.g., consider this Makefile:
>
> var := $(shell echo "echo hi" >say_hi.sh;
This makefile example should help clear things up:
$ cat makefile
SHELL := bash
.RECIPEPREFIX := >
blah1 := test1
blah2 := test2
export blah2
# blah2 & blah3 should have identical results
export blah3 := test3
default:
>@$(foreach x,blah1 blah2 blah3 blah4 blah5,echo "${x}: (origin = $(origin
${x
"Warlich, Christof" writes:
>> > I'm not sure though if this is intended behavior or just a bug
>
>> Well, actually I am using version 4.1 and I do see the difference, are
>> you sure it is not working as intended ?
>
> Well, as I said above, I'm definitely not sure. I would most likely consider
> Is there a Make bug report where I could try to raise a bug ?
See http://lmgtfy.com/?q=gnu+make+bug+reports :-)
___
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-make
