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

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

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

Move opensslconf.h.in to include/openssl.
Split off DES,BN,RC4 stuff into separate header file
templates in crypto/include/internal/*_conf.h.in

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

Some test programs may depend on more than just one TLS version, for
example.

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

This is an internal facility, never documented, not for
public consumption.  Move it into ssl (where it's only used
for DTLS).

I also made the typedef's for pqueue and pitem follow our style: they
name structures, not pointers.

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

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

The explanation is that it falls back to using tools/c_rehash if
'apps/openssl rehash' isn't supported on the platform at hand.

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

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>

GH: #580

Simplify BUF_MEM init. code

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>

GH: #580

Now that configdata.pm is the centre of information, use that instead
of Makefile to figure out reconfiguration parameters.  This will help
future development with different Makefile file names.

The code to read necessary configuration data from Makefile is retained
for an easy transition to configdata.pm based information gathering.  It
will be removed later on.

This change includes moving the variable $cross_compile_prefix to %config.

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

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

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

When experimental-store is enabled, it does not compile due to the
change to opaque data structures.

Change CRYPTO_add() to EVP_PKEY_up_ref() as needed.

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>

RT: #4263, GH: #579

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

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

The turn has come to have crypto/opensslconf.h.in get run through
util/dofile.pl.  The consequence is that a large number of variables
get moved to the %config table.

Also, the string variables $openssl_*, which were populated with cpp
lines, all being of the form "#define SOMETHING", were converted into
ARRAY refs in %config values, containing just the list of macros to be
defined.

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

For this adaptation, the variables $options and $version needed to
move to %config in Configure, and why not move all other variables
holding diverse version numbers at the same time?

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

This includes a start on how to install missing modules.

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

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

Because we're using Text::Template and we know it's a non core Perl
module, we choose to bundle it into our source, for convenience.

external/perl/Downloaded.txt document what modules we choose to bundle
this way and exactly where we downloaded it from.

With this changes comes the transfer module for with_fallback.

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

For our own convenience, we need a mechanism to be able to fall back
on bundled Perl modules.  It's a minimal package that's called like
this:

    use with_fallback qw(Module1 Module2 ...);

For each module, it will try to require them from the system
installation, and failing that, it will temporarly add external/perl
and try to require transfer::{ModuleName}.  It requires that each
bundled Perl modules is accompanied by a small transfer module
(external/perl/transfer/ModuleName.pm in our example) that knows
exactly what to load.

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

apps/CA.pl and tools/c_rehash are built from template files.  So far,
this was done by Configure, which created its own problems as it
forced everyone to reconfigure just because one of the template files
had changed.
Instead, have those files created as part of the normal build in apps/
and in tools/.

Furthermore, this prepares for a future where Configure may produce
entirely other build files than Makefile, and the latter can't be
guaranteed to be the holder of all information for other scripts.
Instead, configdata.pm (described below) becomes the center of
configuration information.

This introduces a few new things:

%config         a hash table to hold all kinds of configuration data
                that can be used by any other script.
configdata.pm   a perl module that Configure writes.  It currently
                holds the hash tables %config and %target.
util/dofile.pl  a script that takes a template on STDIN and outputs
                the result after applying configuration data on it.
                It's supposed to be called like this:

                        perl -I$(TOP) -Mconfigdata < template > result

                or

                        perl -I$(TOP) -Mconfigdata templ1 templ2 ... > result

                Note: util/dofile.pl requires Text::Template.

As part of this changed, remove a number of variables that are really
just copies of entries in %target, and use %target directly.  The
exceptions are $target{cflags} and $target{lflags}, they do get copied
to $cflags and $lflags.  The reason for this is that those variable
potentially go through a lot of changes and would rather deserve a
place in %config.  That, however, is for another commit.

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

It's time for print_table_entry to get a bit of refreshment.  The way it
was put together, we needed to maintain the list of known configuration
keys of interest twice, in different shapes.  This is error prone, so
move the list of strings to a common list for all printing cases, and
use simple formatting of lines to do the actual printout based on that
list.

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

The code is trying to interpolate the value of the BASE_SECTION macro,
but due to excess escaping, it instead prints the string "BASE_SECTION".

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Some things to ignore need to be properly rooted, and use a bit more
precision on ignoring 'lib', as that maybe be a perfectly valid
directory name to add into git elsewhere in the source tree.

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

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

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Change to reflect changes in dynamic_fns

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Reviewed-by: Matt Caswell <matt@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>

--prefix is now exclusively used for software and manual installation.
--openssldir is not exclusively used as a default location for certs,
keys and the default openssl.cnf.

This change is made to bring clarity, to have the two less
intertwined, and to be more compatible with the usual ways of software
installation.

Please change your habits and scripts to use --prefix rather than
--openssldir for installation location now.

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

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

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

It's time to refactor the handling of %disabled so that all
information of value is in the same place.  We have so far had a few
cascading disable rules in form of code, far away from %disabled.
Instead, bring that information to the array @disable_cascade, which
is a list of pairs of the form 'test => descendents'.  The test part
can be a string, and it's simply checked if that string is a key in
%disabled, or it can be a CODEref to do a more complex test.  If the
test comes true, then all descendents are disabled.  This check is
performed until there are no more things that need to be disabled.

Also, $default_depflags is constructed from the information in
%disabled instead of being a separate string.  While a string of its
own is visually appealing, it's much too easy to forget to update it
when something is changed in %disabled.

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