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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
