In message <14082121323639_20200...@antinode.info> on Thu, 21 Aug 2014 21:32:36
-0500, "Steven M. Schweda" <s...@antinode.info> said:
sms> From: Richard Levitte <rich...@levitte.org>
sms>
sms> > There is some similar package for Perl, isn't there? Is that very
sms> > much of a pain? [...]
sms>
sms> I expect it to be one more thing which many people won't have. I
sms> seem to have a Compaq/HP-sourced v5.8.6 ("Compiled at Mar 6 2008
sms> 06:07:12"), and newer stuff is probably available, but a quick search
sms> finds much old stuff. Of course, the tests currently expect perl,
sms> right? (And what I have seems to work.) And "bc", if you want to do
sms> the big-number tests without dragging a non-VMS system into the act.
sms> Hence:
sms>
sms> http://antinode.info/dec/sw/bc.html
Cool. And for Perl installation kits, I found this:
http://sourceforge.net/projects/vmsperlkit/files/
sms> > I'm behind on things, it seems... there are symlinks in VMS these
sms> > days?
sms>
sms> Since V8.3, at least (which is at least seven years old), but V8.4
sms> may have fewer bugs.
Ok. I don't recall that makevms.com has ever been modified to handle
the presence of real symlinks, but my memory may be foggy on that one,
or it happened when I was away.
sms> > That must have happened while I looked away... did you extract
sms> > the "tar" kit with some other tool than the trusty old VMSTAR, or has
sms> > VMSTAR learned to handle symlinks? I haven't looked at VMSTAR in
sms> > ages, but back when I tinkered with it, it didn't have that
sms> > capability.
sms>
sms> Define "trusty old". I adopted VMSTAR about seven years ago, adding
sms> basic symlink support then. It's been better than completely lame (I
sms> claim) since about 2011. That's pretty old, and I tend to trust it.
sms>
sms> http://antinode.info/dec/sw/vmstar.html
Well, "trusty old" is before your go at it, so version 3.4-1. Quite a
lot you've done with it since, cool.
sms> Zip 3.0 and UnZip 6.00 (and up, also not very new) on VMS can handle
sms> them, too.
Good to know...
sms> > My absolutely first aim with this effort is exactly to not having to
sms> > do the silly update of modules in the DCL scripts any more. The
sms> > information is already there in the Makefiles, there's really no good
sms> > reason why the information should be duplicated like it currently is.
sms>
sms> Except that nothing on VMS can use those Makefiles directly. So the
sms> question becomes how to derive anything which _is_ useful on VMS from
sms> the normal source kit. With the auxiliary question being _what_ to
sms> derive (.COM or .MMS, or ???). It's very clear that getting the module
sms> lists from any files which _are_ maintained would be nice, but what to
sms> do with them is less clear (to me).
Well... those Makefiles still have useful information in them ;-)
You know the variables in the DCL scripts? Like all the LIB_* in
[.crypto]crypto-lib.com? They are derived from the LIBOBJ variable in
the corresponding Makefiles. The variable ENCRYPTION_TYPES (which is
really a very silly name) is basically SDIRS with 'Basic' added in the
front to represent the modules in [.crypto]. This has been done
manually so far, but it isn't very hard to read it directly from the
Makefiles. It just needs doing. OR, we could use [.util]files.pl,
which is used to put together all that information into one file
(on Windows, the result is used by util/mk1mf.pl to make one big
makefile... we could do something similar for VMS, derive a MMS...
quite a lot of the bits and pieces are already there, see)
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
