Reviewed-by: Richard Levitte <levitte@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: Rich Salz <rsalz@openssl.org>

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

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

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

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

To begin with, the default should have been the import library, not
the DLL itself.  However, we don't know what directory it's installed
in either way, so we may as well demand the full path from the user

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

The macros ZLIB and ZLIB_SHARED weren't appropriately defined,
deviating wrongly from how they worked in earlier OpenSSL versions.
So, restore it so that ZLIB is defined if configured "enable-zlib" and
so that ZLIB and ZLIB_SHARED are defined if configured
"enable-zlib-dynamic".

Additionally, correct the interpretation of the --with-zlib-lib value
on Windows and VMS, where it's used to indicate the actual zlib
zlib library file / logical name, as that can differ depending on zlib
version and packaging on those platforms.

Finally for Windows and VMS, we also define the macro LIBZ with that
file name / logical name when configured "zlib-dynamic", so the
compression unit can pick it up and use it.

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

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

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

This introduces the settings loutflag and aroutflag, because different
Windows tools that do the same thing have different ways to specify
the output file.

The Borland C++ config is commented away for the monent, perhaps
permanently.

Reviewed-by: Rich Salz <rsalz@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: Richard 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: Matt Caswell <matt@openssl.org>

Reviewed-by: Matt Caswell <matt@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: Andy 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: Andy 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: Andy 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: Andy Polyakov <appro@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: Andy Polyakov <appro@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: Andy Polyakov <appro@openssl.org>

Adding uplink and applink to some builds was done by "magic", the
configuration for "mingw" only had a macro definition, the Configure
would react to its presence by adding the uplink source files to
cpuid_asm_src, and crypto/build.info inherited dance to get it
compiled, and Makefile.shared made sure applink.o would be
appropriately linked in.  That was a lot under the hood.

To replace this, we create a few template configurations in
Configurations/00-base-templates.conf, inherit one of them in the
"mingw" configuration, the rest is just about refering to the
$target{apps_aux_src} / $target{apps_obj} in the right places.

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

These two functions take a separator to concatenat the strings with as
first argument.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

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

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

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

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

As part of this, change util/mkdef.pl to stop adding libraries to
depend on in its output.  mkdef.pl should ONLY output a symbol
vector.

Because symbol names can't be longer than 31 characters, we use the
compiler to shorten those that are longer down to 23 characters plus
an 8 character CRC.  To make sure users of our header files will pick
up on that automatically, add the DEC C supported extra headers files
__decc_include_prologue.h and __decc_include_epilogue.h.

Furthermore, we add a config.com, so VMS people can configure just as
comfortably as any Unix folks, thusly:

    @config

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

With some compilers, C macros are defined differently on the command
line than on Unix.  It could be that the flad to define them isn't -D,
it could also be that they need to be grouped together and not be mixed
in with the other compiler flags (that's how it's done on VMS, for
example).

On Unix family platform configurations, we can continue to have macro
definitions mixed in with the rest of the flags, so the changes in
Configurations/*.conf are kept to an absolute minimum.

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

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

Reviewed-by: Tim Hudson <tjh@openssl.org>

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

The "unified" build scheme revolves around small information files,
build.info, which each describe their own bit of everything that needs
to be built, using a mini-language described in Configurations/README.

The information in build.info file contain references to source files
and final result.  Object files are not mentioned at all, they are
simply from source files.  Because of this, all the *_obj items in
Configurations/*.conf are renamed to *_asm_src and the files listed
in the values are change from object files to their corresponding
source files.  For the sake of the other build schemes, Configure
generates corresponding *_obj entries in %target.

Furthermore, the "unified" build scheme supports having a build
directory tree separate from the source directry tree.

All paths in a build.info file is assumed to be relative to its
location, either within the source tree or within the build tree.

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

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

A few more sub-joins could be replaced with calls to add() and add_before()

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

- Small rearrangement of the TABLE and HASH printouts, and adding
  printout of the "build_scheme" item
- Renamed "engines_obj" to "padlock_obj"
- Moved the runs of dofile down...  it didn't quite make sense to have
  that in the middle of a printout

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

It is time for Makefile.org to fold into the new regime and have a run
through util/dofile.pl.  This forces some information out of there and
into Configure, which isn't a bad thing, it makes Configure
increasingly the center of build information, which is as it should
be.

A few extra defaults were needed in the BASE template to get rid of
warnings about missing values.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Time to get rid of @MK1MF_Builds and introduce a more flexible
'build_scheme' configuration key.  Its value may be a string or an
array of strings, meaning we need to teach resolve_config how to
handle ARRAY referenses.

The build scheme is a word that selects a function to create the
appropriate result files for a certain configuration.  Currently valid
build schemes aer "mk1mf" and "unixmake", the plan is however to add
at least one other for a more universal build scheme.

Incidently, this also adds the functions 'add' and 'add_before', which
can be used in a configuration, so instead of having to repeatedly
write a sub like this:

	key1 => sub { join(" ", @_, "myvalues"); },
	key2 => sub { join(" ", "myvalues", @_); },

one could write this:

	key1 => add(" ", "myvalues"),
	key2 => add_before(" ", "myvalues"),

The good point with 'add' and 'add_before' is that they handle
inheritances where the values are a misture of scalars and ARRAYs.  If
there are any ARRAY to be found, the resulting value will be an ARRAY,
otherwise it will be a scalar with all the incoming valued joined
together with the separator given as first argument to add/add_before.

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

Move the documentation of the target configuration form to
Configurations/README.

Move initial assembler object templates to
Configurations/00-BASE-templates.conf.

Furthermore, remove all variables containing the names of the
non-assembler object files and make a BASE template of them instead.
The  values from this templates are used as defaults as is.  The
remaining manipulation of data when assembler modules are used is done
only when $no_asm is false.

While doing this, clean out some other related variables that aren't
used anywhere.

Also, we had to move the resolution of the chosen target a bit, or the
function 'asm' would never catch a true $no_asm...  this hasn't
mattered before we've moved it all to the BASE template, but now it
does.

At the same time, add the default for the 'unistd' key to the BASE
template.

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