Reviewed-by: NRich Salz <rsalz@openssl.org>

OpenSSL engines are tied to the OpenSSL shared library versions,
starting with OpenSSL 1.1.  We therefore need to install them in
directories which have the shared library version in it's name, to
easily allow multiple OpenSSL versions to be installed at the same
time.

For VMS, the change is a bit more involved, primarly because the top
installation directory was already versioned, *as well as* some of the
files inside.  That's a bit too much.  Version numbering in files is
also a bit different on VMS.  The engines for shared library version
1.1 will therefore end up in OSSL$INSTROOT:[ENGINES0101.'arch']

('arch' is the architecture we build for)
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

When creating the library $lib.olb, make sure the extension is there.
Otherwise, a logical name with the same name as the file in question
will redirect the creation elsewhere.
Reviewed-by: NTim Hudson <tjh@openssl.org>

On VMS, it's customary to have a procedure to check that the software
was installed correctly and can run as advertised.

The procedure added here is fairly simple, it checks that all
libraries are in place, that the header crypto.h is in place, and that
the command 'openssl version -a' runs without trouble.
Reviewed-by: NRich Salz <rsalz@openssl.org>

- The install top is versioned by default.  However, only the major
  version should be used.
- the default areas for certs, private keys an config files have
  changed, now all prefixed with 'OSSL$'.  This gets reflected in
  cryptlib.h.
- [.VMS]openssl_startup.com.in had some faults regarding creating
  rooted concealed logical names.
Reviewed-by: NRich Salz <rsalz@openssl.org>

This makes it possible for script writers to lock on to a specific
version if they need to.  Note that only the major version number is
used.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Also, have the static library file names contain the pointer size when
applicable.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

- User targets are now the same and generally do the same things
- configdata.pm depends on exactly the same files on all platforms
- VMS production of shared libraries is simplified
- VMS automatic dependency files get the extension .D rather than .MMS
Reviewed-by: NRich Salz <rsalz@openssl.org>

Just like in the other build file templates
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

As well as properly generating those that are made from .in files.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

They were using the wrong variables.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

With Unixly Makefiles as well as with nmake, make variables are
transferred to the shell running the commands as envinronment
variables.  This principle doesn't apply with MMS, so we must
explicitely define VERBOSE as commands when it's needed.
Reviewed-by: NRich Salz <rsalz@openssl.org>

When compiling all other C files, rely on the compiler to
automatically pick up the name translation information from the header
files __DECC_INCLUDE_{PRO,EPI}LOGUE.H.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

In the case of generating a file like this:

    GENERATE[foo.S]=mkfoo.pl arg1 arg2

the 'mkfoo.pl' generator itself might need to include other files,
such as perl modules within our source tree.  We can reuse already
existing syntax for it, like this:

    INCLUDE[mkfoo.pl]=module/path

or:

    DEPEND[mkfoo.pl]=modules/mymodule.pm

This change implements the support for such constructs, and for the
DEPEND statement, for any value that indicates a perl module (.pm
file), it will automatically infer an INCLUDE statement for its
directory, just like it does for C header files, so you won't have do
write this:

    DEPEND[mkfoo.pl]=modules/mymodule.pm
    INCLUDE[mkfoo.pl]=modules
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

no-stdio does not work with the apps. Since the tests also need the apps
it doesn't support that either. Therefore we disable building of both.

no-autoalginit is not compatible with the apps because it requires explicit
loading of the algorithms, and the apps don't do that. Therefore we disable
building the apps for this option. Similarly the tests depend on the apps
so we also disable the tests. Finally the whole point about no-autoalginit
is to avoid excessive executable sizes when doing static linking. Therefore
we disable "shared" if this option is selected.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The handling was Unix centric, already in Configure.  Change that to
just collect the value and let the build file templates figure out
what to do with it.
Reviewed-by: NMatt Caswell <matt@openssl.org>

[.test]ssltest.c was renamed to [.test]ssltest_old.c, reflect that in
descrip.mms.tmpl.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

On Windows and Unix, the staging directory $(DESTDIR) can simply be
prepended to the installation directory.  An attempt was made to do
something similar on VMS, but that ended up being a half measure
solution.  Instead of that, simply use the staging directory as a
prefix under which [.OPENSSL-INSTALL] and [.OPENSSL-COMMON] will hold
the two directory trees that should end up in the directories
indicated by --prefix and --openssldir, and finish the installation
with appropriate instructions on what to do next.
Reviewed-by: NRich Salz <rsalz@openssl.org>

- on VMS, SYS$COMMON:[SSL] is already used as installation directory
  by HP SSL, so we make our default for --openssldir
  SYS$COMMON:[OPENSSL-COMMON] instead.
- Updated notes on default installation dirs fir Unix and Windows
Reviewed-by: NRich Salz <rsalz@openssl.org>

Sometimes, you might end up with a rather long compile line due to
excessively long /INCLUDE directories.  Compensate for it by making
a temporary logical name with them and using said logical name as
/INCLUDE argument.

A note was added to NOTES.VMS regarding these limitations.
Reviewed-by: NRich Salz <rsalz@openssl.org>

generatesrc() did already receive dependency information, but never
used it, and never really needed to...  until now.
Reviewed-by: NRich Salz <rsalz@openssl.org>

In most builds, we can assume that engines live in the build tree
subdirectory "engines".  This was hard coded into the tests that use
the engine ossltest.

However, that hard coding is tedious, it would need to be done in
every test recipe, and it's an incorrect assumption in some cases.

This change has us play it safe and let the build files tell the
testing framework where the engines are.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

VMS doesn't have "makedepend" anyway, so this is just a matter of using
the right qualifiers when 'makedepend' is enabled.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>