VMS doesn't have "makedepend" anyway, so this is just a matter of using
the right qualifiers when 'makedepend' is enabled.
Reviewed-by: NRich Salz <rsalz@openssl.org>

For assembler, we want the final target to be foo.s (lowercase s).
However, the build.info may have lines like this (note upper case S):

    GENERATE[foo.S]=foo.pl

This indicates that foo.s (lowercase s) is still to be produced, but
that producing it will take an extra step via $(CC) -E.  Therefore,
the following variants (simplified for display) can be generated:

    GENERATE[foo.S]=foo.pl  =>  foo.s: foo.pl
                                	$(PERL) $foo.pl $@.S; \
                                	$(CC) $(CFLAGS) -E -P $@.S > $@ && \
                                	rm -f $@.S

    GENERATE[foo.s]=foo.pl  =>  foo.s: foo.pl
                                	$(PERL) $foo.pl $@

    GENERATE[foo.S]=foo.m4  =>  foo.s: foo.m4
                                	m4 -B 8192 $foo.m4 > $@.S; \
                                	$(CC) $(CFLAGS) -E -P $@.S > $@ && \
                                	rm -f $@.S

    GENERATE[foo.s]=foo.m4  =>  foo.s: foo.m4
                                	m4 -B 8192 $foo.m4 > $@
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Make all scripts produce .S, make interpretation of $(CFLAGS)
pre-processor's responsibility, start accepting $(PERLASM_SCHEME).
[$(PERLASM_SCHEME) is redundant in this case, because there are
no deviataions between Solaris and Linux assemblers. This is
purely to unify .pl->.S handling across all targets.]
Reviewed-by: NRichard Levitte <levitte@openssl.org>

For config targets such as 'dist', which doesn't have a BASE template,
we still need to have a default build scheme.

Additionally, the unified Makefile template's target 'tar' wasn't
quite as flexible as the unixmake one.

Finally, .travis-create-release.sh can be somewhat simplified now that
it builds with the unified build scheme.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

Should it be needed because the recipes within a RAW section might
clash with those generated by Configure, it's possible to tell it
not to generate them with the use of OVERRIDES, for example:

    SOURCE[libfoo]=foo.c bar.c

    OVERRIDES=bar.o
    BEGINRAW[Makefile(unix)]
    bar.o: bar.c
        $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $<
    ENDRAW[Makefile(unix)]
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

In some cases, one might want to generate some source files from
others, that's done as follows:

    GENERATE[foo.s]=asm/something.pl $(CFLAGS)
    GENERATE[bar.s]=asm/bar.S

The value of each GENERATE line is a command line or part of it.
Configure places no rules on the command line, except the the first
item muct be the generator file.  It is, however, entirely up to the
build file template to define exactly how those command lines should
be handled, how the output is captured and so on.
Reviewed-by: NRich Salz <rsalz@openssl.org>

When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them.  Our solution was to use -fno-common when compiling
C source.

Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition.  -fno-common doesn't help in this case.

However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.

The common conclusion is, either use -fno-common or ranlib -c on
Darwin.  Since we have common block symbols unconditionally, choosing
the method for our source is easy.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

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

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

This construct in a Makefile is a bit overzealous:

	@echo FOO
	@FOO

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

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

We copied $target{cflags}, $target{defines} and a few more to %config,
just to add to the entries.  Avoid doing so, and let the build templates
deal with combining the two.

There are a few cases where we still fiddle with %target, but that's
acceptable.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags.  Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.

Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).

Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.

The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config.  Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Instead, make the build type ("debug" or "release") available through
$config{build_type} and let the configs themselves figure out what the
usual settings (such as "cflags", "lflags" and so on) should be
accordingly.

The benefit with this is that we can now have debug and release
variants of any setting, not just those Configure supports, and may
also involve other factors (the MSVC flags /MD[d] and /MT[d] involve
both build type and whether threading is enabled or not)
Reviewed-by: NAndy Polyakov <appro@openssl.org>

$target{lflags} and $target{plib_flag} were copied to %config for no
good reason.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Configure had the Unix centric addition of -lz when linking with zlib
is enabled, which doesn't work on other platforms.  Therefore, we move
it to the BASE_unix config template and add corresponding ones in the
other BASE_* config templates.  The Windows one is probably incomplete,
but that doesn't matter for the moment, as mk1mf does it's own thing
anyway.

This required making the %withargs table global, so perl snippets in
the configs can use it.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

These BASE templates are intended to hold values that are common for
all configuration variants for whole families of configurations.

So far, three "families" are identified: Unix, Windows and VMS, mostly
characterised by the build system they currently use.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

This has no real meaning, except it gives Configure a hint that VC
targets are indeed capable of producing shared objects.
Reviewed-by: NMatt Caswell <matt@openssl.org>

There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones.  The best way to
solve this is to separate the two.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

Exiting out of a recipe more than necessary leaves an ugly message.
Reviewed-by: NRich Salz <rsalz@openssl.org>

When building with GNU C, clang or VMS C, it's more efficient to
generate dependency file and object file in one call rather than two.
Have the dependency output in a temporary file and compare it with the
previous one if available to see if replacement is waranted, thereby
avoiding unnecessary reconstruction of Makefile / descrip.mms.

Github issue #750
Reviewed-by: NRich Salz <rsalz@openssl.org>

I read the PROBLEMS, and they're outdated; nothing I'd put in the
online FAQ, for example.  Test-builds work without using these files.
Had to remove the rehash.time stuff from Makefile.in
Reviewed-by: NRichard Levitte <levitte@openssl.org>

We don't want recipes for the same files generated more than once
Reviewed-by: NRich Salz <rsalz@openssl.org>

Signed-off-by: NRich Salz <rsalz@akamai.com>
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

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

Since the configs were remade into hash tables, this isn't needed
any more.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

They now default to " " as separator, but that can be overridden by
having a hash with parameters as last argument.  The only currently
recognised parameter is `separator'.

The special separator `undef' will force the result to become a list
rather than a concatenated string.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

If the local system doesn't have GNU C or clang, and not even
makedepend, the build will stop because the call of 'makedepend'
fails.  This changes so the build won't stop because of such failure.
The result will be empty .d files, and that's ok.
Reviewed-by: NRich Salz <rsalz@openssl.org>

These flags are limitting needlessly, are often patched by packagers,
and should be specified on the configuration command line by anyone
who desires for it to be specific rather than forced by us.

This work was already done with mingw when those configs were worked
on, now it gets applied to the remaining configs.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

On slower file systems, this makes a huge difference
Reviewed-by: NRich Salz <rsalz@openssl.org>

GNU make will re-exec if (it thinks that) the Makefile has changed.
Just having the target Makefile seems to make it think it has, so we
end up in a look where GNU make re-execs for ever.

The fix is easy, just remove the Makefile target and have the depend
target run the recipe on its own instead of depending on Makefile.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

is a .s).
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Don't check for no_shared
Reviewed-by: NRich Salz <rsalz@openssl.org>

This takes us away from the idea that we know exactly how our static
libraries are going to get used.  Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.

On the other hand, we also have greater control of when the shared
library cflags.  They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.

With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).
Reviewed-by: NRich Salz <rsalz@openssl.org>