Re: GNU make release candidate 4.1.90 available for download

[h.becker]

On 04/24/2016 08:06 PM, Paul Smith wrote:
> On Sun, 2016-04-24 at 11:45 +0200, h.becker wrote:
>> Build on VMS (V8.3/Alpha) fails with:
>> $ @makefile
>> ...
>> Compiling function...
>>
>> # define vfork fork
>> ...............^
>> %CC-W-MACROREDEF, The redefinition of the macro "vfork" conflicts with 
>> a current  definition because one is object-like and the other is 
>> function-like.  The redefinition is now in effect.
>> at line number 141 in file USR_ODS5:[BECKER_H.make-4^.1^.90]makeint.h;1
> 
> Oops that's my bad.  autoconf handles this for me so I don't need that
> #define.  I'll fix it.

There is one more warning about a redefinition:

Compiling job...

# define vfork fork
...............^
%CC-W-MACROREDEF, The redefinition of the macro "vfork" conflicts with a
current definition because one is object-like and the other is
function-like.  The redefinition is now in effect.
at line number 141 in file USR_ODS5:[BECKER_H.make-4^.1^.90]makeint.h;1

#define NEXT_TOKEN { if (cmd_tkn_index < MAX_DCL_TOKENS) \
...................^
%CC-W-MACROREDEF, The redefinition of the macro "NEXT_TOKEN" conflicts
with a current definition because one is object-like and the other is
function-like.  The redefinition is now in effect.
at line number 267 in file USR_ODS5:[BECKER_H.make-4^.1^.90]vmsjobs.c;2

>> However, a simple VMS test fails - I don't see any relation to the
>> missing function. Or, as there is so much GNV in this version, are VMS
>> lexical functions no longer expected to work?
>>
>> $ ty x.mf
>> all:
>>         write sys$$output "all: ''f$$time()'"
> 
> This I can't answer; John Malmberg will have to give details.  However,
> I see this in the README.VMS:
> 
>>   The default is currently the old behavior when running GNU Make from DCL.
>>   In the future this may change.  When running make from GNV Bash the new
>>   behavior is the default.
> 
> It looks to me like you started your test from GNV Bash?  There should
> be a way to get the old behavior even when starting from bash.  A quick
> read implies that enabling the GNV$MAKE_OLD_VMS setting may help.  Check
> the README.VMS file for more details and verify.

No, this test starts from DCL and setting GNV$MAKE_OLD_VMS doesn't
change anything. (From the name it sounds like a GNV setting, anyway and
not a setting for VMS.)