Re: vms:test variables

[h.becker]

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
picture.

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

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
at all).

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.

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.
- change the "port" of the makefile regarding redirection and what's echoed.