Re: patch for .SHELLFLAGS and .POSIX

[David Boyce]

Following is my original response. It looks you may have seen this
plus the bogus empty response, but I send it again just to be sure.

On Sat, Oct 3, 2009 at 10:05 PM, David Boyce <address@hidden> wrote:
> On Sat, Oct 3, 2009 at 3:14 PM, Paul Smith <address@hidden> wrote:
>> Looks about right.  One open question is, what do we do about the
>> $(shell ...) function?  Do we use the value of $(SHELL) $(.SHELLFLAGS)
>> for this?  Or just always use /bin/sh -c?  I can see arguments both
>> ways.
>
> My first reaction is that it should always use /bin/sh -c. Or more precisely, 
> that it should be regarded as the way to get access to system() from a 
> Makefile.
>
> To put it a little differently, there's no explicit contract about running 
> "the shell" in a recipe, as witness the fast-path optimization. OTOH, when 
> you call $(shell ...) the contract is clearly "the shell", specifically 
> (IMHO) the system shell. But I can also believe that an argument could be 
> made the other way. Let's wait and see if someone does so.
>
>> One concern is whether we should support expanding of .SHELLFLAGS; this
>> version just takes the value verbatim (doesn't it?)  What if someone
>> wanted to do something like:
>>
>>        .SHELLFLAGS = -$(if $(DEBUG),x)c
>>
>> or something like that?
>
> Seems to me the reasonable thing is to handle .SHELLFLAGS the same as SHELL. 
> Is SHELL allowed to do
>
>        SHELL = /bin/$(if $(IMAFOOL),c)sh
>
> ??
>
>> The other thing is replacing "-" with "/" on OS/2.  I wonder if we
>> should not bother to do that, at least not for values that the user
>> sets.  That is, for the default value setting we can use /c if __EMX__
>> is defined, but after that we just use whatever is in .SHELLFLAGS
>> verbatim; if the user sets that value then they can figure out what it
>> should be.  Automatically modifying values like this makes me very
>> uncomfortable in general.
>
> Done, because I agree with the sentiment. Remember though that there's a 
> slight semantic change here because the old version changed '-' to '/' only 
> if (!unixy_shell). I don't believe that's been determined at the time I'm 
> initializing .SHELLFLAGS so it becomes an unequivocal /c. Seems to me the 
> few-if-any people using a unixy shell on OS/2 can just set .SHELLFLAGS
>
>> I don't think you need to set the "special" flag on .SHELLFLAGS.  This
>> is a marker to GNU make that there is something about this variable that
>> needs to be addressed as soon as the variable is set: for
>> example, .POSIX needs to set the posix_pedantic flag etc.
>
> Removed.
>
> -David
>
>