On 04/15/2014 03:06 PM, John E. Malmberg wrote: > The fix there is on VMS to replace "echo > $@" with: > 'open/write xxx $@ ; write xxx "" ; close xxx'
Yes, that should do the trick as other possible fixes can do the same. > Perl choosing logical names as the default for implementing %ENV has > turned out to be a major bug. It is causing a lot of problems with > porting programs and with the Perl self tests and also the perl > makemaker, along with issues with the make test harness. Can of worms? I didn't want or intend to open it, I just wanted to describe what I observed. If GNU make for VMS uses local symbols for exporting make variables it should work. > If the recursive make is exec(), then there is a variant that allows an > environment array to be passed. This is the way that Bash passes > exported variables to children. I thought of that: there is more than just exec and it looks like a major rewrite of the VMS version for child_execute_job. > Yes a general export routine that saves the old value/state of a local > DCL symbol on something like a linked list, creates a new local > variable, and an atexit() routine that restores everything off of the list. Looks like less code than a rewrite but is still a significant piece of code/work. > But we also need to get symbol substitution working in the spawned DCL > command. Either by translating the makefile to use one of the VMS > substitutions or by having the wrapper to lib$spawn do a shell emulation > for such variables. Which symbol substitution? The forced symbol substitution isn't done, but the automatic ones are. With a changed makefile it will work. It's the old trick echo GNUMAKEFLAGS = $$GNUMAKEFLAGS will become write sys$output "GNUMAKEFLAGS = ",GNUMAKEFLAGS _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
