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: NRich Salz <rsalz@openssl.org>

Reviewed-by: NMatt Caswell <matt@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: NRich 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: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NAndy 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: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard 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: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@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>

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>

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: NStephen Henson <steve@openssl.org>

Reviewed-by: NRich Salz <rsalz@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: NMatt Caswell <matt@openssl.org>

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

Add Configure generated header files to $unified_info{generate}.  This
makes sure the build files will pick them up with the rest for the
GENERATED macro, and thereby make sure they get cleaned away by 'make
clean'
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

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

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

- "/Ox /O2 /Ob2" get's reduced to "/O2", the reason being:

    /Ox = /Ob2 /Og /Oi /Ot /Oy /Gs
    /O2 = /Ob2 /Og /Oi /Ot /Oy /Gs /GF /Gy

- apps/openssl.cnf gets installed.

- always delete files quietly, as they might not be there.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1075)

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

- some Perl versions are allergic to missing ';';
- don't stop if del fails;
- omit unused environment variable;
Reviewed-by: NStephen Henson <steve@openssl.org>

If environment variables are not explanded early enough, expanded
strings are passed with single backslash to C compiler, e.g.
C:\Program Files, which effectively results in OpenSSL looking for
engines and certificates in C:Program Files.
Reviewed-by: NRichard Levitte <levitte@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>

Because we have a directory 'test', the target 'test' may be confusing
to make.  However, if we make it depend on 'tests', which doesn't
exist, make should never fail to run the actions.
Reviewed-by: NAndy Polyakov <appro@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>

Without proper cleanup after DLL link failure second attempt to
run nmake would actually proceed and failure will be "shifted" to
run time. This is because libcrypto.lib import library is generated
even if DLL link fails.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Previously, we updated the static libraries (libcrypto.a on Unix,
libcrypto.lib on Windows) with all the object files, regardless of if
they were rebuilt or not.  With this change, we only update them with
the object files were rebuilt.

NOTE: this does not apply on VMS, as the expansion of $? may be too
large for a command line.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

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

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

utils/mkrc.pl was added a while ago as a better generator for the
Windows DLL resource file.  Finalize the change by removing the
ms/version32.rc generator from Configure and adding resource file
support using mkrc.pl in Configurations/windows-makefile.pl
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Closes RT#4447
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

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>

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

On Windows, we set INSTALLTOP to default as follows:

  VC-WIN32:

    PREFIX:     %ProgramFiles(x86)%\OpenSSL
    OPENSSLDIR: %CommonProgramFiles(x86)%\SSL

  VC-WIN64*:

    PREFIX:     %ProgramW6432%\OpenSSL
    OPENSSLDIR: %CommonProgramW6432%\SSL

Should those environment variables be missing, the following is used
as fallback:

    PREFIX:     %ProgramFiles%\OpenSSL
    OPENSSLDIR: %CommonProgramFiles%\SSL
Reviewed-by: NAndy Polyakov <appro@openssl.org>

util/mkdef.pl assumes it knows what the resulting library name will
be.  Really, it shouldn't, but changing it will break classic native
Windows builds, so we leave it for now and change the LIBRARY line
externally when needed instead.
Reviewed-by: NMatt Caswell <matt@openssl.org>

The variable SHARED_CFLAGS and SHARD_LDFLAGS were used in the Unix
template because they normally contain options used when building
"shared".  The Windows template, on the other hand, uses LIB_CFLAGS,
to express the intended use of those flags rather than their content.
The Windows template still used SHARED_LDFLAGS, which seems
inconsistent.

To harmonize the two, any SHARED_CFLAGS gets renamed to LIB_CFLAGS and
SHARED_LDFLAGS to LIB_LDFLAGS.  That makes the intent consistent along
with BIN_{C,LD}FLAGS and DSO_{C,LD}FLAGS.

Finally, make sure to pass down $(LIB_CFLAGS) or $(DSO_CFLAGS) along
with $(CFLAGS) when using Makefile.shared.
Reviewed-by: NRich Salz <rsalz@openssl.org>