Re: vms:test variables

[John E. Malmberg]

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

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

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

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.

Regards,
-John