[openssl-dev] Upcoming build system change

[Steven M. Schweda]

> - Perl!  Reports tell me that version 5.10.1 works fine [...]

   Perhaps, but around here, the current version fails pretty badly:

ALP $ perl --version

This is perl 5, version 22, subversion 1 (v5.22.1) built for VMS_AXP

   The generated descrip.mms is defective.  It starts out reasonable,
with stuff like:

SRCDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
BUILDDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]

but many (supposedly relative) derived paths are bad.  For example:

        DEFINE SRCTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
        DEFINE BLDTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
        $(PERL) [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.test]run_tests.pl $(TESTS)

copy-certs :
        @ IF F$SEARCH("[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]certs.dir") .EQS. "" THEN -
             CREATE/DIR [.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.certs]

and so on.  With all this device-directory confusion ("DISK$UTIL5ALPX:"
v. "[.DISK$UTIL5ALPX]"), failures come thick and fast.

   Apparently, all the realpath() and abs2rel() stuff does horrible
things on VMS in some circumstances (like mine).  My default
device:[directory] spec does not include the DISK$volume_label device
name:

ALP $ show default
  UTILITY5_DEV:[UTILITY.source.openssl.openssl-refactor-build]

ALP $ show logical UTILITY5_DEV
   "UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)

ALP $ show logical DISK$UTIL5ALPX
   "DISK$UTIL5ALPX" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)

   If there's a requirement to use the DISK$volume_label device name,
then there needs to be some (seriously restrictive and/or confusing)
documentation, or else some improved automation to set it as required.

   If Perl can't do this work reliably on VMS, then it might make more
sense to derive such directories/paths using DCL, and let Perl do the
stuff which can be done more portably.

   Knowing approximately nothing about Perl, I'm ill-equipped to
contribute much more to this discussion than complaints about how badly
it works, but I'm open to requests for details or more testing.  For a
little recent, related Perl-on-VMS discussion, there's a thread on
comp.os.vms: 

https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo

   I still don't know why the CPAN stuff failed here, but it did.

   I don't object to Perl being required to build OpenSSL, but if the
OpenSSL builders are sensitive to Perl versions, or to fine details in
how the user specifies his default dev:[dir], then I predict abundant
complaints from a large fraction of VMS users who try to build this
stuff.  (Which may not be a large number, of course.)

   I fetched my openssl-refactor-build.zip kit around 14-JAN-2016, so if
significantly changes were made since then, then I don't know about
them.

>     ! There is no install target yet.
>     ! As a matter of fact, I'd like to talk about exactly where it
>     ! should install.  Let's talk!

   Because VMS lacks a popular default localtion (like /usr/local), I
suggest asking the victim where he'd like it.

> Feedback welcome!

   I'm almost always willing to complain.

------------------------------------------------------------------------

   Steven M. Schweda               sms at antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547