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

On non-Windows platforms, shared libraries are both development and
runtime files.  We only installed them as development files, this
makes sure they get installed as runtime files as well.
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>

Reviewed-by: NRich Salz <rsalz@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>

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

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

Also, make sure that per-file deps are included in the build, even if previous
builds have failed.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@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>

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

Reviewed-by: NRichard Levitte <levitte@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: NRichard Levitte <levitte@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: NMatt Caswell <matt@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>

RT#2558
Reviewed-by: NTim Hudson <tjh@openssl.org>

Some setups use links inside .git directory and make clean should not
remove them to avoid breaking git meta-information.
Signed-off-by: NCristian Stoica <cristian.stoica@nxp.com>

CLA: none; trivial
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1078)

Some non-Gnu compilers interpret -E -P combination differently.
some prioritize -E over -P, others -P over -E (in which case .i
file is generated and sometimes truncated because of redirection).
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

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

Script obj_dat.pl depends on file obj_mac.h generated by script objects.pl
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@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>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@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>

We used to symlink generate_ssl_tests.pl to the build directory.
Now that the build scripts look for sources in both directories, this
is no longer necessary (see commit
fbd361ea).
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Currently, SSL tests are configured via command-line switches to
ssltest.c. This results in a lot of duplication between ssltest.c and
apps, and a complex setup. ssltest.c is also simply old and needs
maintenance.

Instead, we already have a way to configure SSL servers and clients, so
we leverage that. SSL tests can now be configured from a configuration
file. Test servers and clients are configured using the standard
ssl_conf module. Additional test settings are configured via a test
configuration.

Moreover, since the CONF language involves unnecessary boilerplate, the
test conf itself is generated from a shorter Perl syntax.

The generated testcase files are checked in to the repo to make
it easier to verify that the intended test cases are in fact run; and to
simplify debugging failures.

To demonstrate the approach, min/max protocol tests are converted to the
new format. This change also fixes MinProtocol and MaxProtocol
handling. It was previously requested that an SSL_CTX have both the
server and client flags set for these commands; this clearly can never work.

Guide to this PR:
 - test/ssl_test.c - test framework
 - test/ssl_test_ctx.* - test configuration structure
 - test/handshake_helper.* - new SSL test handshaking code
 - test/ssl-tests/ - test configurations
 - test/generate_ssl_tests.pl - script for generating CONF-style test
   configurations from perl inputs
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>

The logic to find out of there are any .d files newer than Makefile is
sound.  Checking the result was less so.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

- In Configure, register the perl interpreter used to run Configure,
  so that's the one being used throughout instead of something else
  that Configure happens to find.  This is helpful for using a perl
  version that's not necessarely first in $PATH:

    /opt/perl/5.22.1/bin/perl ./Configure

- Make apps/tsget a generated file, just like apps/CA.pl, so the
  perl interpreter registered by Configure becomes the hashbang path
  instead of a hardcoded /usr/bin/perl
Reviewed-by: NAndy Polyakov <appro@openssl.org>