Re: VMS progname and exit handling - Take 4

[h.becker]

On 04/02/2014 07:15 AM, John E. Malmberg wrote:
> On 4/1/2014 4:22 PM, h.becker wrote:
>> On 04/01/2014 06:41 AM, John E. Malmberg wrote:
>>> If you have the make variable be a MCR command, it has a space which can
>>> have side effects when if the resulting string is processed by other
>>> strings or macros.
>>
>> You mentioned this already. Can you point me to an example where this
>> fails? Is this in a test, which I couldn't run so far?
> 
> For the $(MAKE), macro, I do not have an example.

OK, so when I have the tests running, I'll give it a try. (I manually
converted a few makefiles created by the tests, to see if my new code
for ONESHELL works as expected.)

> In the tests though, several examples show up where the VMS specific
> change to have some macros return "," delimiters instead of " "
> delimiters broke the tests and required some workarounds.
> 
> That is why adding an unexpected space to the value returned by a
> standard macro can be predicted to have problems.
> 
> With 20/20 hindsight, a new set of macros should have been created that
> returned the data with comma delimiters that could have been used with
> VMS specific rules and recipes.  That can not be done now with out
> breaking backward VMS compatibility.
> 
> But having a set of functions to easily swap commas for spaces and the
> reverse would probably still be useful to add, as it would be more
> convenient than the hack I had to use.

As far as I understand you are testing GNV, you are not testing VMS. No
suprise that there are problems with the special variables, which have
comma delimiters ($+, $^, $?). I think I already said this, from my
point of view, a GNV GNU make should be separated from a VMS GNU make.
Here, in commands.c, you want to have the FILE_LIST_SEPARATOR defined as
' ' and not as ',' as it is in the #if VMS: you need to turn off the VMS
macro or add an own GNV macro.