On Fri, 2016-09-23 at 13:24 +, Edward Welbourne wrote:
>> This does seem like an unsound choice, for the reasons David gave,
Paul Smith replied:
> Perhaps but as discussed, it's been that way in GNU make (and other
> versions of make) forever and is required by the POSIX standard. So
> we'll j
On Sun, 2016-09-25 at 11:26 -0700, David Boyce wrote:
> While the behavior of setting MAKEFLAGS in the makefile may be
> undefined, its behavior when encountered in environment seems to be
> made clear by this statement and GNU make still seems wrong there:
I've filed an enhancement request for co
First I'm going to disagree, a bit with myself and a bit with Philip,
because I had not focused sufficiently on the keyword "environment" in
"Macros defined by the MAKEFLAGS _environment_ variable ... shall not be
added to the environment". While the behavior of setting MAKEFLAGS in the
makefile ma
On Fri, 2016-09-23 at 16:09 -0700, David Boyce wrote:
> "Macros defined by the MAKEFLAGS environment variable and macros
> defined in the makefile(s) shall not be added to the environment of
> make if they are not already in its environment."
That text is not in the currently published version of
On Fri, Sep 23, 2016 at 4:09 PM, David Boyce wrote:
> In that case there does seem to be at least one bug here. In reference to
> the sentence:
>
> "Macros defined by the MAKEFLAGS environment variable and macros defined in
> the makefile(s) shall not be added to the environment of make if they ar
In that case there does seem to be at least one bug here. In reference to
the sentence:
"Macros defined by the MAKEFLAGS environment variable and macros defined in
the makefile(s) shall not be added to the environment of make if they are
not already in its environment."
And building on Eddy Welbo
On Fri, Sep 23, 2016 at 11:23 AM, Paul Smith wrote:
> On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote:
>> I still think that's a good plan, except that now I find out it ends
>> up exporting anyway. I'm sure it's too late to change now but is
>> there a reason for this (unfortunate IMHO) beha
David Boyce observed:
> I was unpleasantly surprised to learn while following this discussion
> that "Except by explicit request, make exports a variable only if it
> is either defined in the environment initially _or set on the command
> line_".
... and I was surprised to find (by experiment with
On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote:
> I still think that's a good plan, except that now I find out it ends
> up exporting anyway. I'm sure it's too late to change now but is
> there a reason for this (unfortunate IMHO) behavior?
I can't tell you: this behavior has existed since t
Changing the subject a bit, I was unpleasantly surprised to learn while
following this discussion that "Except by explicit request, make exports a
variable only if it is either defined in the environment initially _or set
on the command line_". For years I've noticed a tendency for users to mark
va
Paul Smith writes:
> On Tue, 2016-09-20 at 15:28 +, Pietro wrote:
>> Hi,
>>
>> I have noticed that there is a difference between the two scenarios
>> listed below:
>>
>> i) make CC=arm-linux-gnueabihf-gcc CPPFLAGS=[..]
>>
>> ii) export CPPFLAGS=[..] [RET]
>> make CC=arm-linux-gnueabih
On Tue, 2016-09-20 at 15:28 +, Pietro wrote:
> Hi,
>
> I have noticed that there is a difference between the two scenarios
> listed below:
>
> i) make CC=arm-linux-gnueabihf-gcc CPPFLAGS=[..]
>
> ii) export CPPFLAGS=[..] [RET]
> make CC=arm-linux-gnueabihf-gcc
>
> I was told that the d
Hi,
I have noticed that there is a difference between the two scenarios
listed below:
i) make CC=arm-linux-gnueabihf-gcc CPPFLAGS=[..]
ii) export CPPFLAGS=[..] [RET]
make CC=arm-linux-gnueabihf-gcc
I was told that the difference is that in the second case Make
will append stuff to the CPPF
13 matches
Mail list logo
