Configure: Engage ecp_nistz256-armv8 module.

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

Configure: engage ARMv8 Montgomery multiplication module.

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

Use -Wall -Wextra with clang

The disabled set of -Weverything is hard to maintain across versions.
Use -Wall -Wextra but also document other useful warnings that currently trigger.

Use -Wall -Wextra with clang

The disabled set of -Weverything is hard to maintain across versions.
Use -Wall -Wextra but also document other useful warnings that currently trigger.

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

show more ...

Add -Wtype-limits to strict warnings.

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

Appease clang -Wgnu-statement-expression

We use GNU statement expressions in crypto/md32_common.h, surrounded
by checks that GNU C is indeed used to compile. It seems that clang,
at

Appease clang -Wgnu-statement-expression

We use GNU statement expressions in crypto/md32_common.h, surrounded
by checks that GNU C is indeed used to compile. It seems that clang,
at least on Linux, pretends to be GNU C, therefore finds the statement
expressions and then warns about them.

The solution is to have clang be quiet about it.

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

show more ...

Stop symlinking, move files to intended directory

Rather than making include/openssl/foo.h a symlink to
crypto/foo/foo.h, this change moves the file to include/openssl/foo.h
once and

Stop symlinking, move files to intended directory

Rather than making include/openssl/foo.h a symlink to
crypto/foo/foo.h, this change moves the file to include/openssl/foo.h
once and for all.

Likewise, move crypto/foo/footest.c to test/footest.c, instead of
symlinking it there.

Originally-by: Geoff Thorpe <geoff@openssl.org>

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

show more ...

Engage vpaes-armv8 module.

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

Configure: remove unused variables.

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

Add -DDEBUG_UNUSED to --strict-warnings

In order to receive warnings on unused function return values the flag
-DDEBUG_UNUSED must be passed to the compiler. This change adds that for th

Add -DDEBUG_UNUSED to --strict-warnings

In order to receive warnings on unused function return values the flag
-DDEBUG_UNUSED must be passed to the compiler. This change adds that for the
--strict-warnings Configure option.

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

show more ...

Refer to $table{$target} rather than $table{$t}.

Using $t is an artifact from the earlier changes in Configure and was
unfortunately forgotten as is.

Reviewed-by: Stephen Henson

Refer to $table{$target} rather than $table{$t}.

Using $t is an artifact from the earlier changes in Configure and was
unfortunately forgotten as is.

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

show more ...

If the target is an old style debug- target, it will not have debugging [cl]flags

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

Configure: fold related configurations more aggressively and clean-up.

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

Correct the request of debug builds

./config would translate -d into having the target get a 'debug-'
prefix, and then run './Configure LIST' to find out if such a
debugging target e

Correct the request of debug builds

./config would translate -d into having the target get a 'debug-'
prefix, and then run './Configure LIST' to find out if such a
debugging target exists or not.

With the recent changes, the separate 'debug-foo' targets are
disappearing, and we're giving the normal targets debugging
capabilities instead. Unfortunately, './config' wasn't changed to
match this new behavior.

This change introduces the arguments '--debug' and '--release' - the
latter just for orthogonality - to ./Configure, and ./config now
treats -d by adding '--debug' to the options for ./Configure.

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

show more ...

Change all the main configurations to the new format.

As part of this, remove some levitte examples that never were relevant.

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

Rethink templates.

Because base templates express inheritance of values, the attribute is
renamed to 'inherit_from', and texts about this talk about 'inheritance(s)'
rather than base

Rethink templates.

Because base templates express inheritance of values, the attribute is
renamed to 'inherit_from', and texts about this talk about 'inheritance(s)'
rather than base templates.

As they were previously implemented, base templates that were listed
together would override one another, the first one acting as defaults for
the next and so on.

However, it was pointed out that a strength of inheritance would be to
base configurations on several templates - for example one for CPU, one
for operating system and one for compiler - and that requires a different
way of combining those templates. With this change, inherited values
from several inheritances are concatenated by default (keep on reading).

Also, in-string templates with the double-curly syntax are removed,
replaced with the possibility to have a configuration value be a coderef
(i.e. a 'sub { /* your code goes here */ }') that gets the list of values
from all inheritances as the list @_. The result of executing such a
coderef on a list of values is assumed to become a string. ANY OTHER
FORM OF VALUE WILL CURRENTLY BREAK.

As a matter of fact, an attribute in the current config with no value is
assumed to have this coderef as value:

sub { join(' ', @_) }

While we're at it, rename debug-[cl]flags to debug_[cl]flags and
nodebug-[cl]flags to release_[cl]flags.

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

show more ...

Add base template processing.

Base templates are templates that are used to inherit from. They can
loosely be compared with parent class inheritance in object orientation.
They can

Add base template processing.

Base templates are templates that are used to inherit from. They can
loosely be compared with parent class inheritance in object orientation.
They can be used for the same purpose as the variables with multi-field
strings are used in old-style string configurations.

Base templates are declared with the base_templates configuration
attribute, like so:

"example_target" => {
base_templates => [ "x86_asm", ... ]
...
}

Note: The value of base_templates MUST be an array reference (an array
enclosed in square brackets).

Any configuration target can be used as a base template by another. It
is also possible to have a target that's a pure template and not meant to
be used directly as a configuration target. Such a target is marked with
the template configuration attribute, like so:

"example_template" => {
template => 1,
cc => "mycc",
...
},

As part of this commit, all variables with multi-field strings have been
translated to pure templates. The variables currently remain since we
can't expect people to shift to hash table configurations immediately.

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

show more ...

Add template reference processing.

Template references are words with double brackets, and refer to the
same field in the target pointed at the the double bracketed word.

For ex

Add template reference processing.

Template references are words with double brackets, and refer to the
same field in the target pointed at the the double bracketed word.

For example, if a target's configuration has the following entry:

'cflags' => '-DFOO {{x86_debug}}'

... then {{x86_debug}} will be replaced with the 'cflags' value from
target 'x86_debug'.

Note: template references are resolved recursively, and circular
references are not allowed

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

show more ...

Rewrite Configure to handle the target values as hash tables.

The reasoning is that configuration strings are hard to read and error
prone, and that a better way would be for them to be

Rewrite Configure to handle the target values as hash tables.

The reasoning is that configuration strings are hard to read and error
prone, and that a better way would be for them to be key => value hashes.

Configure is made to be able to handle target configuration values as a
string as well as a hash. It also does the best it can to combine a
"debug-foo" target with a "foo" target, given that they are similar
except for the cflags and lflags values. The latter are spliced into
options that are common for "debug-foo" and "foo", options that exist
only with "debug-foo" and options that exist only with "foo", and make
them into combinable attributes that holds common cflags, extra cflags
for debuggin and extra cflags for non-debugging configurations.

The next step is to make it possible to have template configurations.

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

show more ...

Move Configurations* out of the way and rename them.

Configure would load the glob "Configurations*". The problem with
this is that it also loads all kinds of backups of those
confi

Move Configurations* out of the way and rename them.

Configure would load the glob "Configurations*". The problem with
this is that it also loads all kinds of backups of those
configurations that some editors do, like emacs' classic
'Configurations~'. The solution is to give them an extension, such as
'.conf', and make sure to end the glob with that.

Also, because 'Configurations.conf' makes for a silly name, and
because a possibly large number of configurations will become clutter,
move them to a subdirectory 'Configurations/', and rename them to
something more expressive, as well as something that sets up some form
of sorting order. Thus:

Configurations -> Configurations/10-main.conf
Configurations.team -> Configurations/90-team.conf

Finally, make sure that Configure sorts the list of files that 'glob'
produces, and adapt Makefile.org.

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

show more ...

Move build config table to separate files.

Move the build configuration table into separate files. The Configurations
file is standard configs, and Configurations.team is for openssl-te

Move build config table to separate files.

Move the build configuration table into separate files. The Configurations
file is standard configs, and Configurations.team is for openssl-team
members. Any other file, Configurations*, found in the same directory
as the Configure script, is loaded.

To add another file, use --config=FILE flags (which should probably be
an absolute path).

Written by Stefen Eissing <stefan.eissing@greenbytes.de> and Rich Salz
<rsalz@openssl.org>, contributed by Akamai Technologies.

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

show more ...

Restore -DTERMIO/-DTERMIOS on Windows platforms.

The previous defaulting to TERMIOS took away -DTERMIOS / -DTERMIO a
bit too enthusiastically. Windows/DOSish platforms of all sorts get

Restore -DTERMIO/-DTERMIOS on Windows platforms.

The previous defaulting to TERMIOS took away -DTERMIOS / -DTERMIO a
bit too enthusiastically. Windows/DOSish platforms of all sorts get
identified as OPENSSL_SYS_MSDOS, and they get a different treatment
altogether UNLESS -DTERMIO or -DTERMIOS is explicitely given with the
configuration. The answer is to restore those macro definitions for
the affected configuration targets.

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

show more ...

Assume TERMIOS is default, remove TERMIO on all Linux.

The rationale for this move is that TERMIOS is default, supported by
POSIX-1.2001, and most definitely on Linux. For a few other s

Assume TERMIOS is default, remove TERMIO on all Linux.

The rationale for this move is that TERMIOS is default, supported by
POSIX-1.2001, and most definitely on Linux. For a few other systems,
TERMIO may still be the termnial interface of preference, so we keep
-DTERMIO on those in Configure.

crypto/ui/ui_openssl.c is simplified in this regard, and will define
TERMIOS for all systems except a select few exceptions.
Reviewed-by: Matt Caswell <matt@openssl.org>

show more ...

Engage ecp_nistz256-armv4 module.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Configure: disable warning C4090 in Windows builds.

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

Remove -DOPENSSL_NO_DEPRECATED from --strict-warnings flags.

In master OPENSSL_NO_DEPRECATED is the default anyway. By including it in
--strict-warnings as well this means you cannot com

Remove -DOPENSSL_NO_DEPRECATED from --strict-warnings flags.

In master OPENSSL_NO_DEPRECATED is the default anyway. By including it in
--strict-warnings as well this means you cannot combine enable-deprecated
with --strict-warnings.

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

show more ...