> - 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@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
