Re: vms:test variables

[John E. Malmberg]

On 4/8/2014 12:48 PM, h.becker wrote:
> On 04/08/2014 07:28 AM, John E. Malmberg wrote:
> > On 4/7/2014 4:37 PM, h.becker wrote:
> > > $ @TEST_MAKE
> > >
> > > features.dir/archives ...................................
> >           ^^^^^^

> > This is a day one bug in the older Perl on VMS versions that was fixed
> > in about the Perl 5.10 timeframe, but the fix was not made the default
> > behavior until Perl 5.18, as it is tied to supporting EFS character
> > filenames.
>
> test_make did not complain about the perl version so I concluded perl
> is/was OK. It seems it isn't:
> $ perl "-V"
> Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
> ...

The test is mainly testing for the older Perl 5.8.x from the HP kit to 
avoid using it.  Craig Berry did a manual custom install of 5.10 on 
Encompasserve that looks a lot like the new PCSI kit install for 5.18, 
so the test_make.com procedure did not detect that it was an older Perl.

I will find out if Craig Berry has time to update Perl on Encompasserve, 
or if he is ok if I just do it.

> > Perl 5.18 and later suppresses the incorrect ".dir" being appended to
> > paths by default.  The incorrect behavior can be optionally turned on
> > for existing PERL/VMS scripts that expect the buggy behavior.  I did not
> > test the script with older versions of Perl, or with the older behavior
> > enabled.
>
> and can the incorrect behavior turned off in older versions? (OK,
> temporarily I can change run_make_tests.pl).

$DEFINE DECC$EFS_CHARSET ENABLE

Should do the trick.  That turns off most of the backwards behavior.
As long as there are not any ODS-5 specific files in the directory, the 
older behavior mostly works.

Some other DECC$ logicals may also be needed for fixing various bugs in 
the UNIX format file name parsing, as the CRTL is by default maintaining 
backwards compatibility for programs that are expecting buggy behavior.

Most of the fixes should be in Perl 5.10, just not enabled by default.

> > > OK, I can run one when I specify one, but it fails due to bash's ":":
> >
> > It is not failing, the warning from DCL is written out, but does not
> > otherwise affect the execution.  Rather than modify all the tests that
> > were using ":" as null command, I changed the compare_output routine in
> > the test harness to ignore it.
>
> Make, at least the version I made, propagates the DCL warning and stops
> with an error:
>
> $ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk_2
> undefined
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> work/variables/undefine.mk_2:11: recipe for target 'all' failed
> make: *** [all] Error 0x380b0
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> $ ed "^UP^work/variables/undefine.mk_2
>      1
> *s/@:/@continue/W
>     11       all: ;@continue
> 1 substitution
> *exit
> USR_ODS5:[BECKER_H.make.x.tests]UNDEFINE.MK_2;1 11 lines
>
> $ rena UNDEFINE.MK_2;1 "^UP^work/variables/undefine.mk_2
> $ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk_2
> undefined
> $

> GNU make doesn't care about the commands, but either my make (likely, or
> maybe) behaves, or the used commands (I don't see any in this test case)
> behave, or the test environment behaves differently:
>
> $ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk
> recursive simple recursive
> undefined undefined undefined
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> work/variables/undefine.mk:19: recipe for target 'all' failed
> make: *** [all] Error 0x380b0
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> $
>
> and with the replacement for ":":
> $ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk
> recursive simple recursive
> undefined undefined undefined
> $
>
> but in the log/diff created under control of the perl script there is
>
> $ ty "^UP^work/variables/undefine.log
> recursive simple recursive
>
> undefined undefined recursive
>
> $ ty "^UP^work/variables/undefine.diff
> *** work/variables/undefine.base        Tue Apr  8 13:22:21 2014
> --- work/variables/undefine.log Tue Apr  8 13:22:21 2014
> ***************
> *** 1,2 ****
>    recursive simple recursive
> ! undefined undefined undefined
> --- 1,4 ----
>    recursive simple recursive
> !
> ! undefined undefined recursive
> !
> $
>
> which matches your output. This is at least confusing, one would expect
> to see the same output in a stand-alone run and in a run under the
> control of the perl script.

That is something that needs to be investigated.  Something about 
running in the test script is changing the behavior of GNU make for a 
few tests.

I saw only about 2 cases where a test passed when I manually ran the 
makefile and it failed on the test harness.

I am sure that the test harness and tests will need further changes as 
we progress, and that we will need to add tests to explicitly test for 
intentional VMS differences in behavior.

Regards,
-John