The list of programs hit nmake's maximum line length, so we split up the
line in smaller chunks.

Fixes #3634
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3636)

The trick is to use the .a extension explicitely in the build.info files.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3243)

jom is an nmake clone that does parallell building, via the same -j
argument as GNU make.  To make it work, we need to apply the same
dependeency build up as done in 27c40a93

Fixes #3272
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3277)

Very simply, support having the .a extension to denote depending on
static libraries.  Note that this is not supported on native Windows
when building shared libraries, as there is not static library then,
just an import library with the same name.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1889)

Pre 1.1.0, 'make test' would set the environment variable
OPENSSL_DEBUG_MEMORY to "on".  This got lost when translating the old
build files to the new templates.  This changes reintroduces that
variable.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1840)

While we're at it, correct the fault in windows-makefile.tmpl
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

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

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

Instead, install the new one as openssl.cnf.dist (openssl.cnf-dist on
VMS), and only install it as openssl.cnf if that file doesn't already
exist.

Also, don't install with exec privileges on VMS.
Reviewed-by: NRich Salz <rsalz@openssl.org>

This adds a new target 'build_programs' and makes 'build_apps' and
'build_tests' aliases for it, for backward compatibility.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

With a number of tools, especially those coming with Visual Studio,
some command options are separated from their argument with a space,
others with a space.  Since we parametrise them, we can't know
beforehand which it will be, so we must allow the input and output
options to have either.

However, spaces at the end of nmake macro values are trimmed, so allow
spaces to exist by adding a reference to an undefined macro at the end.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

This is only done for the platforms where 'OPENSSL_USE_APPLINK' is defined.

Also, change the docs of OPENSSL_Applink to say where to find applink.c
in the installation directory.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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: NRich 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: 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 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>