The reason for this is that some of the C flags affect built in macros
that we may depend on.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5436)

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

The make variables LIB_CFLAGS, DSO_CFLAGS and so on were used in
addition to CFLAGS and so on.  This works without problem on Unix and
Windows, where options with different purposes (such as -D and -I) can
appear anywhere on the command line and get accumulated as they come.
This is not necessarely so on VMS.  For example, macros must all be
collected and given through one /DEFINE, and the same goes for
inclusion directories (/INCLUDE).

So, to harmonize all platforms, we repurpose make variables starting
with LIB_, DSO_ and BIN_ to be all encompassing variables that
collects the corresponding values from CFLAGS, CPPFLAGS, DEFINES,
INCLUDES and so on together with possible config target values
specific for libraries DSOs and programs, and use them instead of the
general ones everywhere.

This will, for example, allow VMS to use the exact same generators for
generated files that go through cpp as all other platforms, something
that has been impossible to do safely before now.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

Instead of having the knowledge of the exact flags to run the C
preprocessor only and have it output on standard output in the deeper
recesses of the build file template, make it a config parameter, or
rely on build CPP in value ('$(CC) -E' on Unix).
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5356)

It was a bit absurd to have this being specially handled in the build
file templates, especially that we have the 'includes' attribute.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5296)

The slash should be there according to Microsoft documentation,
see https://msdn.microsoft.com/en-us/library/7cafx990.aspx

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

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5197)

For proper escaping, we need the direct perl variable values, not a
make variable reference.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5196)

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5196)

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

Support the following "make variables":

AR              (GNU compatible)
ARFLAGS         (GNU Compatible)
AS              (GNU Compatible)
ASFLAGS         (GNU Compatible)
CC              (GNU Compatible)
CFLAGS          (GNU Compatible)
CXX             (GNU Compatible)
CXXFLAGS        (GNU Compatible)
CPP             (GNU Compatible)
CPPFLAGS        (GNU Compatible)
CPPDEFINES      List of CPP macro definitions.  Alternative for -D
CPPINCLUDES     List of CPP inclusion directories.  Alternative for -I
HASHBANGPERL    Perl invocation to be inserted after '#!' in public
                perl scripts.
LDFLAGS         (GNU Compatible)
LDLIBS          (GNU Compatible)
RANLIB          Program to generate library archive index
RC              Program to manipulate Windows resources
RCFLAGS         Flags for $(RC)
RM              (GNU Compatible)

Setting one of these overrides the corresponding data from our config
targets.  However, flags given directly on the configuration command
line are additional, and are therefore added to the flags coming from
one of the variables above or the config target.

Fixes #2420
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)

C preprocessor flags get separated from C flags, which has the
advantage that we don't get loads of macro definitions and inclusion
directory specs when linking shared libraries, DSOs and programs.

This is a step to add support for "make variables" when configuring.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5108)

Only when building the main shared libraries

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

Remove some config attributes that just duplicate values that are
already there in other attributes.

Remove the special runs of mkdef.pl and mkrc.pl from build file
templates, as these are now done via GENERATE statements in
build.info.

Remove all references to ordinal files from build file templates, as
these are now treated via the GENERATE statements in build.info.

Also remove -shared flags and similar that are there in shared-info.pl
anyway.  (in the case of darwin, it's mandatory, as -bundle and
-dynamiclib don't mix)
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)

Because this also includes handling all sorts of non-object files when
linking a program, shared library or DSO, this also includes allowing
general recognition of files such as .res files (compiled from .rc
files), or .def / .map / .opt files (for export and possibly
versioning of public symbols only).

This does mean that there's a tangible change for all build file
templates: they must now recognise and handle the `.o` extension,
which is used internally to recognise object files internally.  This
extension was removed by common.tmpl before this change, but would
mean that the platform specific templates wouldn't know if "foo.map"
was originally "foo.map.o" (i.e. an object file in its own right) or
"foo.map" (an export definition file that should be treated as such,
not as an object file).

For the sake of simplifying things, we also modify util/mkdef.pl to
produce .def (Windows) and .opt (VMS) files that don't need additional
hackery.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)

This will replace the use of Makefile.shared

This also means a small adjustment on how the attributes dso_cflags,
dso_cxxflags and dso_lflags are treated.  They were previously treated
as an extension to shared_cflag, shared_cxxflag and shared_ldflag, but
they should really be regarded as alternatives instead, for example
for darwin, where -dynamiclib is used for shared libraries and -bundle
for DSOs.

We take the opportunity to clean out things that are redundant or
otherwise superfluous (for example the check of GNU ld on platforms
where it never existed).
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)

RESULT_D can be used to provide a separate directory for test results.
Let's use that to separate them from other files.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4507)

This avoids issues that can come with an ending backslash, among other.

Fixes #4458
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4461)

This should fix the recent AppVeyor failures.

[extended tests]
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4171)

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4167)

$(SHLIB_MAJOR).$(SHLIB_MINOR) is really a synonym for
$(SHLIB_VERSION_NUMBER), and is therefore an added complexity,
so better to use $(SHLIB_VERSION_NUMBER) directly.  SHLIB_MAJOR and
SHLIB_MINOR are now unused, but are kept around purely as information
in case someone relies on their existence.

At the same time, add support for custom shared library extensions
with the three new Makefile variables SHLIB_EXT, SHLIB_EXT_SIMPLE and
SHLIB_EXT_IMPORT.  By default, they hold the variants of shared
library extensions we support.  On mingw and cygwin, SHLIB_EXT_IMPORT
is defined; on all other Unix platforms, it's empty.

An example to get shared libraries with a slightly different SOVER name:

    $ make SHLIB_EXT='.$(SHLIB_VERSION_NUMBER).so'

Fixes #3902
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3964)

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

This new target is used to build all generated files and only that.
This can be used to prepare everything that requires things like perl
for a system that lacks perl and then move everything to that system
and do the rest of the build there.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3695)

Because apps/progs.h isn't configuration agnostic, it's not at all
suited for 'make update' or being versioned, so change it to be
dynamically generated.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3688)

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>