The easiest way to take care of manifest files is to integrate them
into the associated binary (.exe or .dll).  MT (the Manifest Tool) is
the utility to use for this.

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

With OpenSSL 1.1 and on, the engines are tightly tied to the shared
library they're to be used with.  That makes them depend on the
pointer size as well as the shared library version, and this gets
reflected in the name of the directory they're installed in.

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

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

This mostly affects 'openssl version -a', which might as well display
what we're actually looking at.

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

Some Unix variants require shared libraries to have the execute
permissions set, or they won't be loadable or executable when loaded.
Among others, cygwin has this requirement.

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

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

$openssldir and $enginesdir were mistakenly made unavailable to other
perl fragments.  They are still needed in the definition of CFLAGS.

Reviewed-by: Rich 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: Rich 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 Unix, the default installation directory is changed from
$PREFIX/lib/engines to $PREFIX/lib/engines-${major}_${minor} (mingw)
or $PREFIX/lib/engines-${major}.${minor} (all but mingw)

($PREFIX is the directory given for the configuration option --prefix,
and ${major} and ${minor} are the major and minor shared library
version numbers)

Reviewed-by: Rich 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 windows, the default installation directory is changed from
$PREFIX/lib/engines to $PREFIX/lib/engines-${major}_${minor}

($PREFIX is the directory given for the configuration option --prefix,
and ${major} and ${minor} are the major and minor shared library
version numbers)

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

Reviewed-by: Matt 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: Tim 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: Rich 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: Rich 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: Rich Salz <rsalz@openssl.org>

Also, have the static library file names contain the pointer size when
applicable.

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

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

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

Also, make sure that per-file deps are included in the build, even if previous
builds have failed.

Reviewed-by: Richard Levitte <levitte@openssl.org>

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

$prefix was removed as part of the DESTDIR work.  However, it was
still used to create the ENGINESDIR_dev and ENGINESDIR_dir variables,
so a restoration is needed.

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

DESTDIR can't be used on Windows the same way as on Unix, the device
part of the installation paths get in the way.

To remedy this, have INSTALLTOP, OPENSSLDIR and ENGINESDIR get
different values depending on if $(DESTDIR) is empty or not, and use
$(INSTALLTOP), $(OPENSSLDIR) and $(ENGINESDIR) alone.

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

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

This is just in case someone passed an inclusion path with the
configuration, and there are OpenSSL headers from another version
in there.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Since corresponding rule was removed from windows-makefile.tmpl out
of necessity, question popped if it's appropriate to harmonize even
unix-Makefile.tmpl. Note that as long as you work on single directory
'make lib<rary>.a' is effectively equivalent to 'make <dir/ectory>'
prior this modification.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Problem with Microsoft lib.exe is that it doesn't *update* modules
in .lib archive, but creates new one upon every invocation. As result
if a source file was updated and nmake was executed, a useless archive
with only one module was created. In other words one has to always
pass all .obj modules on command line, not only recently recompiled.

[This also creates dilemma for directory targets, e.g. crypto\aes,
that were added to simplify every-day life for developer. Since
whole idea behind those targets is to minimize the re-compile time
upon single file modification, the only sensible thing to do is to
omit intended library update.]

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich 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: Rich Salz <rsalz@openssl.org>

Just like in the other build file templates

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

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

As well as properly generating those that are made from .in files.

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

'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be
generated before anything else is built.  It's likely that a number
of source files depend on these header files, this provides a simple
way to make sure they are always generated even it the dependency data
hasn't been added to the build file yet.

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

Reviewed-by: Richard Levitte <levitte@openssl.org>

The directories for the final products were never registered, it was
plain luck that intermediary files were in the same place and
registered the directory anyway.

Also, scripts are generated directly from source (binaries go through
intermadiary object files), so we need to explicitely make sure to
avoid registering the source directory unless it's an in source
build.

Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Previous build scheme allowed building just the stuff in one
subdirectory, like this:

    make -C crypto/aes

Because the unified only has a top-level Makefile, this is not
possible with it.  This change adds a replacement where each directory
we have something to build in becomes a target in its own right,
allowing building something like this:

    make crypto/aes

The exception is the directory test, because we already have such a
target.

Reviewed-by: Stephen Henson <steve@openssl.org>

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

Reviewed-by: Richard Levitte <levitte@openssl.org>

This applies when building out-of-source.

RT#4486

NOTE: we can't do the same for Unix, as Unix make doesn't handle this
type of issue.  Also, directory specs are much less likely to have
spaces on Unix...

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

Someone wants to configure like this:

    PERL="/usr/bin/env perl" ./config

The end goal is to get that in the #! line of CA.pl and a few other
scripts.  That works well already, but in the Makefile, there were a
few lines looking like this:

    PERL=$(PERL) $(PERL) whatever.pl ...

Those need some quoting.

RT#4311

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

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