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

It seems that only gcc -MMD produces dependency files that are "sane"
for our needs.  For all other methods, some post processing is needed:

- 'makedepend' (Unix) insists that object files are located in the
  same spot as the source file.
- 'cl /Zs /showIncludes' (Visual C) has "Note: including file: " where
  we'd like to see the object.
- 'CC/DECC' (VMS) insists that the object file is located in the
  current directory, i.e. it strips away all directory information.

So far, we've managed this (except for the VMS case) with individual
uncommented perl command lines directly in the build file template.
We're now collecting these diverse hacks into one perl script that
takes an argument to tell what kind of input to expect and that
massages whatever it gets on STDIN and outputs the result on STDOUT.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)

The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which inherits from
linux-x86_64 and debian [0]. So far so good.

Unless there are different suggestions how to do this, I would keep it.
However since the target name does not start with `linux', the build
system does not enable the afalg engine. So in order to get enabled, I
added a
	`enable           => [ "afalgeng" ],'
to the generic linux config which sets it explicit (as suggested by
Richard Levitte). Having this set, we can check for it instead matching
the target name.

[0] https://sources.debian.org/src/openssl/1.1.0g-2/Configurations/20-debian.conf/Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5169)

We have '--strict-warnings' for this kind of stuff...  also, user
flags are added last, so this overrides any warning supression
--strict-warnings may put in place (for good reasons).

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

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

Move Android targets to separate file, automate sysroot setup and
add support for NDK 16.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5589)

With the help of the perl script util/add-depends.pl, which takes all
its information directly from configdata.pm, the dependency adding
procedure can be streamlined for all support platforms.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5606)

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

So far assembly modules were built as .pl->.S->.s followed by .s->.o.
This posed a problem in build_all_generated rule if it was executed
on another computer. So we change rule sequence to .pl->.S and then
.S->.s->.o.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5573)

A missing parenthesis here, a missing comma there...
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5579)

This includes even ARM targets.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5502)

$target{build_scheme} consists of fixed number of elements with 3rd
element denoting VC install-path "flavour", i.e. where to install things.
Instead of looking at 3rd, let's look at last. This allows to override
flavour from template in a simple way.

Configurations/10-main.conf: define generic "flavour" in VC-common
template. Since VC-W32 was the only recognized "flavour", remove
"flavour" definitions from all targets/templates, but VC-WIN32. And
rename VC-W32 to VC-WOW.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5502)

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

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

We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up.  Quite a
few of those flags are actually only relevant for the libraries
(mostly libcrypto), so it's safe to say that those could be applied to
the libraries only.

So, we move some of those flags to 'lib_defines', 'lib_cppflags',
'lib_cflags', etc.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5560)

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

Travis-ci log output is huge and overflows internal travis-ci view,
which makes it hard to find errors.
Redirect some output to a file and dump it only if it fails.
Remove "v" option from tar that builds and extracts the srcdist.
While running the tests manually, some non-POSIX (bashisms) with ==
vs = came to light.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5555)

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

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

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

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

With the support of "make variables" comes the possibility for the
user to override them.  However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).

Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.

We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

Because there are already attributes with the dso_ prefix that are
used instead of the corresponding lib_ attributes rather than in
addition to them, it gets confusing to have similar or exactly the
same attributes working with different semantics on Unix.

So we rename those by changing the prefix dso_ to module_, and having
those work just like the shared_ attributes, but for DSOs.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

We have never used these variables with the Unix Makefile, and there's
no reason for us to change this, so to avoid confusion, we remove them.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5545)

-fno-common was removed for all Darwin targets in
0c873419 with rationale "it's either
'ranlib -c' or '-fno-common'." However, it's still absolutely required
in 32-bit darwin-ppc-cc. And when trying things out I didn't quite
see why it was formulated as one-or-another choice, as 'ranlib -c'
shouldn't [and doesn't] have problems with object modules without
commons. [Well, to be frank, I didn't manage to reproduce the problem
the modification was meaning to resolve either...]
Reviewed-by: NRich Salz <rsalz@openssl.org>

Rely on the build.info constructor to do the right thing.

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

And only generate one output "file" at a time for objects.pl
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5432)

With this, we introduce the make variable 'libdir', which differs from
'LIBDIR' not only in casing, but also by being the absolute path to
the library installation directory.  This variable is intentionally
compatible with the GNU coding standards.

When --libdir is given an absolute path, it is considered as a value
according to GNU coding standards, and the variables LIBDIR and libdir
will be this:

    LIBDIR=
    libdir=/absolute/path

When --libdir is given a relative path (just the name of the desired
library directory), or not given at all, it is considered as a
"traditional" OpenSSL value, and the variables LIBDIR and libdir will
be this:

    LIBDIR=relativepath
    libdir=$(INSTALLTOP)/$(LIBDIR)

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

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)

If the configured value is the empty string, give them a sane default.
Otherwise, give them the configured value prefix with $(CROSS_COMPILE)
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

It was inconsistent to see this specific command have
'$(CROSS_COMPILE)' in its value when no other command did.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5408)

In previous OpenSSL versions, this letter was part of the make
variable AR.  However, following the usual convention (read: GNU),
this letter is supposed to be part of ARFLAGS.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5386)

Avoid using crypto/modes/ghash-ia64.s, as it uses features that are
explicitely prohibited on VMS.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

This does require the use of a port of 'ias' for VMS.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

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)

All VMS config targets were literally copies of each other, only
differing in what argument the parameter seeking function vms_info()
received (the pointer size).

This could be hugely simplified by letting vms_info() detect what
pointer size was desired from the desired config target name instead.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5364)

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