Make doesn't always treat multiline quoted strings as nicely as one
would wish.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

In unix-Makefile.tmpl, this construction has been used a few times

	if ! something; then ...

It seems, though, that some shells do not understand !, so these need
to be changed.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

When passing down values to Makefile.shared, do so with single quotes
as much as possible to avoid having the shell create a mess of quotes.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The variable SHARED_CFLAGS and SHARD_LDFLAGS were used in the Unix
template because they normally contain options used when building
"shared".  The Windows template, on the other hand, uses LIB_CFLAGS,
to express the intended use of those flags rather than their content.
The Windows template still used SHARED_LDFLAGS, which seems
inconsistent.

To harmonize the two, any SHARED_CFLAGS gets renamed to LIB_CFLAGS and
SHARED_LDFLAGS to LIB_LDFLAGS.  That makes the intent consistent along
with BIN_{C,LD}FLAGS and DSO_{C,LD}FLAGS.

Finally, make sure to pass down $(LIB_CFLAGS) or $(DSO_CFLAGS) along
with $(CFLAGS) when using Makefile.shared.
Reviewed-by: NRich Salz <rsalz@openssl.org>

It turns out that different sed implementations treat -i differently
to cause issues.  make it simpler by avoiding it entirely and give
perl the trust to be consistent enough.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The issue is demonstrated as follows:

  On Linux:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | sed -e 's/ \/\(\\.\|[^ ]\)*//g'
    : foo.h bar.h

  On MacOS X:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | sed -e 's/ \/\(\\.\|[^ ]\)*//g'
    : foo.husr/include/stddef.h bar.h

Perl is more consistent:

  On Linux:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | perl -pe 's/ \/(\\.|[^ ])*//g;'
    : foo.h bar.h

  On MacOS X:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | perl -pe 's/ \/(\\.|[^ ])*//g;'
    : foo.h bar.h
Reviewed-by: NAndy Polyakov <appro@openssl.org>

If pre-processor failed, an empty .s file could be left behind,
which could get successfully compiled if one simply re-ran make
and cause linking failures. Not anymore. Remove even intermediate .S
in case of pre-processor failure.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

One of them didn't clean away .d.tmp files properly.
The other would overwrite the .d files unconditionally, thereby
causing a possibly unnecessary dependency rebuild, which touches the
date of Makefile, which causes a possibly unnecessary rebuild of
buildinf.h and everything that depends on that.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NStephen Henson <steve@openssl.org>

The source file generators sometimes use $(CC) to post-process
generated source, and getting the inclusion directories may be
necessary at times, so we pass them down.

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

This change is a bit more complex, as it involves several recipe
variants.

Also, remove the $(CROSS_COMPILE) prefix for the makedepend program.
When we use the program "makedepend", this doesn't serve anything,
and when we use the compiler, this value isn't even used.
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>

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

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>

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

Reviewed-by: NAndy Polyakov <appro@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>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@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>

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>

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>

It failed to remove lingering Makefile.new
Reviewed-by: NRich Salz <rsalz@openssl.org>

It was turning off output again in two place where it should have
turned it on.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

Better libclean that removes the exact files that have been built,
nothing more and nothing less.

Corrected typo

A couple of editorial changes.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Of course, if there are remaining files in a directory, it won't be removed.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Since we're using the acronym DSO everywhere else and that's a common
name for that kind of object, we might as well do so here as well.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Instead of having the installation recipe rely on special knowledge,
feed it with information, including what shared library files belong
together.  For Cygwin and Mingw, that's the .dll and its import
library .dll.a.  For Unixen, it's the shared library file name with SO
version and the one without.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Originally, the Makefile.shared targets described what they used as
input for a shared object, be it a shared library or a DSO.  It turned
out, however, that the link_o targets were used exclusively for
engines and the link_a targets were for libcrypto and libssl.

This rename fest turns and indication on the kind of input the targets
get to the intention with using them.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

Then it can pass around the information where it belongs.  The
Makefile templates pick it up along with other target data, the
DSO module gets to pick up the information through
crypto/include/internal/dso_conf.h
Reviewed-by: NAndy Polyakov <appro@openssl.org>