[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vms:test variables
John E. Malmberg
Re: vms:test variables
Tue, 15 Apr 2014 08:06:32 -0500
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
On 4/14/2014 3:04 PM, h.becker wrote:
As already mentioned, the last test for variables/GNUMAKEFLAGS fails for
VMS. I think I know why, but I'm not yet sure whether I have the full
There are at least two reasons: the "port" to VMS of the makefile for
this test case is not working as expected and exporting make variables
is not implemented on VMS.
In the test case, in the original mk_string there is
x.mk: ; @echo $@; echo MAKEFLAGS = $$MAKEFLAGS; echo GNUMAKEFLAGS =
$$GNUMAKEFLAGS; echo > $@
which was ported to VMS as
x.mk: ; @pipe echo $@ ; echo MAKEFLAGS = $$MAKEFLAGS ; echo GNUMAKEFLAGS
= $$GNUMAKEFLAGS ; echo > $@
On Unix, all echo commands except the last one write to stdout: only a
single '\n' goes into address@hidden
On VMS, the VMS specific redirection in GNU make forces the output of
all echo commands into address@hidden
The fix there is on VMS to replace "echo > $@" with:
'open/write xxx $@ ; write xxx "" ; close xxx'
On Unix, the shell variables $MAKEFLAGS and $GNUMAKEFLAGS are printed,
on VMS $<mumble> does not reference a DCL symbol (nor are these
variables known to the used GNV echo command, as here is no shell used
That needs a different fix of course.
The GNU make variables MAKEFLAGS and GNUMAKEFLAGS are usually exported
(where GNUMAKEFLAGS is set to an empty string by GNU make). Exporting of
GNU make variables is not implemented for VMS. But GNUMAKEFLAGS is
somehow known and visible when the action routine runs, still holding
its initial value.
When running the test under the control of the perl test script, a shell
variable for a run of GNU make is exported via %ENV. On VMS,
added/changed %ENV items show up in the process logical name table.
This table is visible when GNU make runs and when the actions run.
There may be good reasons why perl for VMS choose to use logical names
for implementing %ENV. Usually an environment variable is retrieved with
getenv(), which, as implemented in the VMS CRTL, "accepts" any local, or
global DCL symbol and any logical name as an environment variable. And
that sequence also describes the order: local symbols are preferred over
global ones and over logical names.
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.
Perl has a mode where it can use DCL symbols, but it it not the default
or well tested.
At this time, the default mode of Perl on VMS can not be easily changed
because of the number of programs that expect this behavior.
logical names act more like symbolic links than they do environment
Even having the CRTL treat logical names as environment variables has
turned out to cause problems.
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.
That means, if someone uses a local DCL symbol to set GNUMAKEFLAGS, GNU
make will see it, use it and will ignore the logical name created by the
perl test script.
To have something working and to pass this test, one needs to
- export exportable make variables, that is create, or save and
overwrite local DCL symbols.
- delete the local DCL symbols which were created and restore those
which were overwritten - at program termination.
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.
- change the "port" of the makefile regarding redirection and what's echoed.
That part is done above.
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.
- Re: vms:test variables, (continued)
- Re: vms:test variables, John E. Malmberg, 2014/04/06
- Re: vms:test variables, h.becker, 2014/04/07
- Re: vms:test variables, John E. Malmberg, 2014/04/08
- Re: vms:test variables, h.becker, 2014/04/08
- Re: vms:test variables, John E. Malmberg, 2014/04/09
- Re: vms:test variables, h.becker, 2014/04/10
- Re: vms:test variables, h.becker, 2014/04/11
- Re: vms:test variables, John E. Malmberg, 2014/04/11
- Re: vms:test variables, h.becker, 2014/04/12
- Re: vms:test variables, h.becker, 2014/04/14
- Re: vms:test variables,
John E. Malmberg <=
- Re: vms:test variables, h.becker, 2014/04/15