#! /usr/bin/env perl
# -*- mode: perl; -*-
##
## Configure -- OpenSSL source tree configuration script
## If editing this file, run this command before committing
## make -f Makefile.org TABLE
##
require 5.000;
use strict;
use File::Basename;
use File::Spec::Functions;
# see INSTALL for instructions.
my $usage="Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] [--config=FILE] os/compiler[:flags]\n";
# Options:
#
# --config add the given configuration file, which will be read after
# any "Configurations*" files that are found in the same
# directory as this script.
# --openssldir install OpenSSL in OPENSSLDIR (Default: DIR/ssl if the
# --prefix option is given; /usr/local/ssl otherwise)
# --prefix prefix for the OpenSSL include, lib and bin directories
# (Default: the OPENSSLDIR directory)
#
# --install_prefix Additional prefix for package builders (empty by
# default). This needn't be set in advance, you can
# just as well use "make INSTALL_PREFIX=/whatever install".
#
# --test-sanity Make a number of sanity checks on the data in this file.
# This is a debugging tool for OpenSSL developers.
#
# --cross-compile-prefix Add specified prefix to binutils components.
#
# no-hw-xxx do not compile support for specific crypto hardware.
# Generic OpenSSL-style methods relating to this support
# are always compiled but return NULL if the hardware
# support isn't compiled.
# no-hw do not compile support for any crypto hardware.
# [no-]threads [don't] try to create a library that is suitable for
# multithreaded applications (default is "threads" if we
# know how to do it)
# [no-]shared [don't] try to create shared libraries when supported.
# no-asm do not use assembler
# no-dso do not compile in any native shared-library methods. This
# will ensure that all methods just return NULL.
# [no-]zlib [don't] compile support for zlib compression.
# zlib-dynamic Like "zlib", but the zlib library is expected to be a shared
# library and will be loaded in run-time by the OpenSSL library.
# sctp include SCTP support
# 386 generate 80386 code
# no-sse2 disables IA-32 SSE2 code, above option implies no-sse2
# no-<cipher> build without specified algorithm (rsa, idea, rc5, ...)
# -<xxx> +<xxx> compiler options are passed through
#
# DEBUG_SAFESTACK use type-safe stacks to enforce type-safety on stack items
# provided to stack calls. Generates unique stack functions for
# each possible stack type.
# DES_PTR use pointer lookup vs arrays in the DES in crypto/des/des_locl.h
# DES_RISC1 use different DES_ENCRYPT macro that helps reduce register
# dependancies but needs to more registers, good for RISC CPU's
# DES_RISC2 A different RISC variant.
# DES_UNROLL unroll the inner DES loop, sometimes helps, somtimes hinders.
# DES_INT use 'int' instead of 'long' for DES_LONG in crypto/des/des.h
# This is used on the DEC Alpha where long is 8 bytes
# and int is 4
# BN_LLONG use the type 'long long' in crypto/bn/bn.h
# MD2_CHAR use 'char' instead of 'int' for MD2_INT in crypto/md2/md2.h
# MD2_LONG use 'long' instead of 'int' for MD2_INT in crypto/md2/md2.h
# IDEA_SHORT use 'short' instead of 'int' for IDEA_INT in crypto/idea/idea.h
# IDEA_LONG use 'long' instead of 'int' for IDEA_INT in crypto/idea/idea.h
# RC2_SHORT use 'short' instead of 'int' for RC2_INT in crypto/rc2/rc2.h
# RC2_LONG use 'long' instead of 'int' for RC2_INT in crypto/rc2/rc2.h
# RC4_CHAR use 'char' instead of 'int' for RC4_INT in crypto/rc4/rc4.h
# RC4_LONG use 'long' instead of 'int' for RC4_INT in crypto/rc4/rc4.h
# RC4_INDEX define RC4_INDEX in crypto/rc4/rc4_locl.h. This turns on
# array lookups instead of pointer use.
# RC4_CHUNK enables code that handles data aligned at long (natural CPU
# word) boundary.
# RC4_CHUNK_LL enables code that handles data aligned at long long boundary
# (intended for 64-bit CPUs running 32-bit OS).
# BF_PTR use 'pointer arithmatic' for Blowfish (unsafe on Alpha).
# BF_PTR2 intel specific version (generic version is more efficient).
#
# Following are set automatically by this script
#
# MD5_ASM use some extra md5 assember,
# SHA1_ASM use some extra sha1 assember, must define L_ENDIAN for x86
# RMD160_ASM use some extra ripemd160 assember,
# SHA256_ASM sha256_block is implemented in assembler
# SHA512_ASM sha512_block is implemented in assembler
# AES_ASM ASE_[en|de]crypt is implemented in assembler
# Minimum warning options... any contributions to OpenSSL should at least get
# past these.
my $gcc_devteam_warn = "-Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Werror -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DDEBUG_UNUSED";
# These are used in addition to $gcc_devteam_warn when the compiler is clang.
# TODO(openssl-team): fix problems and investigate if (at least) the
# following warnings can also be enabled:
# -Wswitch-enum, -Wunused-macros, -Wmissing-field-initializers,
# -Wcast-align,
# -Wunreachable-code -Wunused-parameter -Wlanguage-extension-token
# -Wextended-offsetof
my $clang_devteam_warn = "-Wno-unused-parameter -Wno-missing-field-initializers -Wno-language-extension-token -Wno-extended-offsetof -Wconditional-uninitialized -Qunused-arguments -Wincompatible-pointer-types-discards-qualifiers -Wmissing-variable-declarations";
# These are used in addition to $gcc_devteam_warn unless this is a mingw build.
# This adds backtrace information to the memory leak info.
my $memleak_devteam_backtrace = "-rdynamic -DCRYPTO_MDEBUG_BACKTRACE";
my $strict_warnings = 0;
my $x86_gcc_des="DES_PTR DES_RISC1 DES_UNROLL";
# MD2_CHAR slags pentium pros
my $x86_gcc_opts="RC4_INDEX MD2_INT";
#$bits1="SIXTEEN_BIT ";
#$bits2="THIRTY_TWO_BIT ";
my $bits1="THIRTY_TWO_BIT ";
my $bits2="SIXTY_FOUR_BIT ";
# As for $BSDthreads. Idea is to maintain "collective" set of flags,
# which would cover all BSD flavors. -pthread applies to them all,
# but is treated differently. OpenBSD expands is as -D_POSIX_THREAD
# -lc_r, which is sufficient. FreeBSD 4.x expands it as -lc_r,
# which has to be accompanied by explicit -D_THREAD_SAFE and
# sometimes -D_REENTRANT. FreeBSD 5.x expands it as -lc_r, which
# seems to be sufficient?
my $BSDthreads="-pthread -D_THREAD_SAFE -D_REENTRANT";
# table of known configurations, read in from files
#
# The content of each entry can take one of two forms:
#
# - old style config-string, colon seperated fields with exactly the
# following structure.:
#
# $cc : $cflags : $unistd : $thread_cflag : $sys_id : $lflags : $bn_ops : $cpuid_obj : $bn_obj : $ec_obj : $des_obj : $aes_obj : $bf_obj : $md5_obj : $sha1_obj : $cast_obj : $rc4_obj : $rmd160_obj : $rc5_obj : $wp_obj : $cmll_obj : $modes_obj : $engines_obj : $perlasm_scheme : $dso_scheme : $shared_target : $shared_cflag : $shared_ldflag : $shared_extension : $ranlib : $arflags : $multilib
#
# We use the stringtohash function - defined below - to combine with the
# fields and form a proper hash table from the string.
#
# - direct transfer of old style config string to hash table, using the names
# of the fields as keys:
#
# {
# cc => $cc,
# cflags => $cflags,
# unistd => $unistd,
# thread_cflag => $thread_cflag,
# sys_id => $sys_id,
# lflags => $lflags,
# bn_ops => $bn_ops,
# cpuid_obj => $cpuid_obj,
# bn_obj => $bn_obj,
# ec_obj => $ec_obj,
# des_obj => $des_obj,
# aes_obj => $aes_obj,
# bf_obj => $bf_obj,
# md5_obj => $md5_obj,
# sha1_obj => $sha1_obj,
# cast_obj => $cast_obj,
# rc4_obj => $rc4_obj,
# rmd160_obj => $rmd160_obj,
# rc5_obj => $rc5_obj,
# wp_obj => $wp_obj,
# cmll_obj => $cmll_obj,
# modes_obj => $modes_obj,
# engines_obj => $engines_obj,
# perlasm_scheme => $perlasm_scheme,
# dso_scheme => $dso_scheme,
# shared_target => $shared_target,
# shared_cflag => $shared_cflag,
# shared_ldflag => $shared_ldflag,
# shared_extension => $shared_extension,
# ranlib => $ranlib,
# arflags => $arflags,
# multilib => $multilib
# }
#
# - new style config hash table, which has additional attributes for debug
# and non-debug flags to be added to the common flags, for cflags and lflags:
#
# {
# cc => $cc,
# cflags => $cflags,
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>
8 years ago
# debug_cflags => $debug_cflags,
# release_cflags => $release_cflags,
# unistd => $unistd,
# thread_cflag => $thread_cflag,
# sys_id => $sys_id,
# lflags => $lflags,
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>
8 years ago
# debug_lflags => $debug_lflags,
# release_lflags => $release_lflags,
# bn_ops => $bn_ops,
# cpuid_obj => $cpuid_obj,
# bn_obj => $bn_obj,
# ec_obj => $ec_obj,
# des_obj => $des_obj,
# aes_obj => $aes_obj,
# bf_obj => $bf_obj,
# md5_obj => $md5_obj,
# sha1_obj => $sha1_obj,
# cast_obj => $cast_obj,
# rc4_obj => $rc4_obj,
# rmd160_obj => $rmd160_obj,
# rc5_obj => $rc5_obj,
# wp_obj => $wp_obj,
# cmll_obj => $cmll_obj,
# modes_obj => $modes_obj,
# engines_obj => $engines_obj,
# dso_scheme => $dso_scheme,
# shared_target => $shared_target,
# shared_cflag => $shared_cflag,
# shared_ldflag => $shared_ldflag,
# shared_extension => $shared_extension,
# ranlib => $ranlib,
# arflags => $arflags,
# multilib => $multilib
# }
#
# The configuration reader will do what it can to translate everything into
# new style config hash tables, including merging $target and debug-$target
# if they are similar enough.
#
# The configuration hashes can refer to templates in two different manners:
#
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>
8 years ago
# - as part of the hash, one can have a key called 'inherit_from' that
# indicate what other configuration hashes to inherit data from.
# These are resolved recursively.
#
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>
8 years ago
# Inheritance works as a set of default values that can be overriden
# by corresponding attribute values in the inheriting configuration.
#
# If several configurations are given in the 'inherit_from' array, the
# values of same attribute are concatenated with space separation.
# With this, it's possible to have several smaller templates for
# different configuration aspects that can be combined into a complete
# configuration.
#
# Example:
#
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>
8 years ago
# "foo" => {
# template => 1,
# haha => "haha",
# hoho => "ho"
# },
# "bar" => {
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>
8 years ago
# template => 1,
# hoho => "ho",
# hehe => "hehe"
# },
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>
8 years ago
# "laughter" => {
# inherit_from => [ "foo", "bar" ],
# }
#
# The entry for "foo" will become as follows after processing:
#
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>
8 years ago
# "laughter" => {
# haha => "haha",
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>
8 years ago
# hoho => "ho ho",
# hehe => "hehe"
# }
#
# Note 1: any entry from the table can be used as a template.
# Note 2: pure templates have the attribute 'template => 1' and cannot
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>
8 years ago
# be used as targets.
#
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>
8 years ago
# - instead of a string, one can have a code block of the form
# 'sub { /* your code here */ }', where the arguments are the list of
# inherited values for that key. In fact, the concatenation of strings
# is really done by using 'sub { join(" ",@_) }' on the list of inherited
# values.
#
# Example:
#
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>
8 years ago
# "foo" => {
# template => 1,
# haha => "ha ha",
# hoho => "ho",
# ignored => "This should not appear in the end result",
# },
# "bar" => {
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>
8 years ago
# template => 1,
# haha => "ah",
# hoho => "haho",
# hehe => "hehe"
# },
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>
8 years ago
# "laughter" => {
# inherit_from => [ "foo", "bar" ],
# hehe => sub { join(" ",(@_,"!!!")) },
# ignored => "",
# }
#
# The entry for "foo" will become as follows after processing:
#
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>
8 years ago
# "laughter" => {
# haha => "ha ha ah",
# hoho => "ho haho",
# hehe => "hehe !!!",
# ignored => ""
# }
#
my %table=(
# All these templates are merely a translation of the corresponding
# variables further up.
#
# Note: as long as someone might use old style configuration strings,
# or we bother supporting that, those variables need to stay
x86_asm => {
template => 1,
cpuid_obj => "x86cpuid.o",
bn_obj => "bn-586.o co-586.o x86-mont.o x86-gf2m.o",
ec_obj => "ecp_nistz256.o ecp_nistz256-x86.o",
des_obj => "des-586.o crypt586.o",
aes_obj => "aes-586.o vpaes-x86.o aesni-x86.o",
bf_obj => "bf-586.o",
md5_obj => "md5-586.o",
sha1_obj => "sha1-586.o sha256-586.o sha512-586.o",
rc4_obj => "rc4-586.o",
rmd160_obj => "rmd-586.o",
rc5_obj => "rc5-586.o",
wp_obj => "wp_block.o wp-mmx.o",
cmll_obj => "cmll-x86.o",
modes_obj => "ghash-x86.o",
engines_obj => "e_padlock-x86.o"
},
x86_elf_asm => {
template => 1,
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>
8 years ago
inherit_from => [ "x86_asm" ],
perlasm_scheme => "elf"
},
x86_64_asm => {
template => 1,
cpuid_obj => "x86_64cpuid.o",
bn_obj => "x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o",
aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o",
md5_obj => "md5-x86_64.o",
sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o",
rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
wp_obj => "wp-x86_64.o",
cmll_obj => "cmll-x86_64.o cmll_misc.o",
modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
engines_obj => "e_padlock-x86_64.o"
},
ia64_asm => {
template => 1,
cpuid_obj => "ia64cpuid.o",
bn_obj => "bn-ia64.o ia64-mont.o",
aes_obj => "aes_core.o aes_cbc.o aes-ia64.o",
md5_obj => "md5-ia64.o",
sha1_obj => "sha1-ia64.o sha256-ia64.o sha512-ia64.o",
rc4_obj => "rc4-ia64.o rc4_skey.o",
modes_obj => "ghash-ia64.o",
perlasm_scheme => "void"
},
sparcv9_asm => {
template => 1,
cpuid_obj => "sparcv9cap.o sparccpuid.o",
bn_obj => "bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o vis3-mont.o sparct4-mont.o sparcv9-gf2m.o",
ec_obj => "ecp_nistz256.o ecp_nistz256-sparcv9.o",
des_obj => "des_enc-sparc.o fcrypt_b.o dest4-sparcv9.o",
aes_obj => "aes_core.o aes_cbc.o aes-sparcv9.o aest4-sparcv9.o",
md5_obj => "md5-sparcv9.o",
sha1_obj => "sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o",
cmll_obj => "camellia.o cmll_misc.o cmll_cbc.o cmllt4-sparcv9.o",
modes_obj => "ghash-sparcv9.o",
perlasm_scheme => "void"
},
sparcv8_asm => {
template => 1,
cpuid_obj => "",
bn_obj => "sparcv8.o",
des_obj => "des_enc-sparc.o fcrypt_b.o",
perlasm_scheme => "void"
},
alpha_asm => {
template => 1,
cpuid_obj => "alphacpuid.o",
bn_obj => "bn_asm.o alpha-mont.o",
sha1_obj => "sha1-alpha.o",
modes_obj => "ghash-alpha.o",
perlasm_scheme => "void"
},
mips32_asm => {
template => 1,
bn_obj => "bn-mips.o mips-mont.o",
aes_obj => "aes_cbc.o aes-mips.o",
sha1_obj => "sha1-mips.o sha256-mips.o",
},
mips64_asm => {
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>
8 years ago
inherit_from => [ "mips32_asm" ],
template => 1,
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>
8 years ago
sha1_obj => sub { join(" ", @_, "sha512-mips.o") }
},
s390x_asm => {
template => 1,
cpuid_obj => "s390xcap.o s390xcpuid.o",
bn_obj => "bn-s390x.o s390x-mont.o s390x-gf2m.o",
aes_obj => "aes-s390x.o aes-ctr.o aes-xts.o",
sha1_obj => "sha1-s390x.o sha256-s390x.o sha512-s390x.o",
rc4_obj => "rc4-s390x.o",
modes_obj => "ghash-s390x.o",
},
armv4_asm => {
template => 1,
cpuid_obj => "armcap.o armv4cpuid.o",
bn_obj => "bn_asm.o armv4-mont.o armv4-gf2m.o",
ec_obj => "ecp_nistz256.o ecp_nistz256-armv4.o",
aes_obj => "aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o",
sha1_obj => "sha1-armv4-large.o sha256-armv4.o sha512-armv4.o",
modes_obj => "ghash-armv4.o ghashv8-armx.o",
perlasm_scheme => "void"
},
aarch64_asm => {
template => 1,
cpuid_obj => "armcap.o arm64cpuid.o mem_clr.o",
ec_obj => "ecp_nistz256.o ecp_nistz256-armv8.o",
bn_obj => "bn_asm.o armv8-mont.o",
aes_obj => "aes_core.o aes_cbc.o aesv8-armx.o vpaes-armv8.o",
sha1_obj => "sha1-armv8.o sha256-armv8.o sha512-armv8.o",
modes_obj => "ghashv8-armx.o",
},
parisc11_asm => {
template => 1,
cpuid_obj => "pariscid.o",
bn_obj => "bn_asm.o parisc-mont.o",
aes_obj => "aes_core.o aes_cbc.o aes-parisc.o",
sha1_obj => "sha1-parisc.o sha256-parisc.o sha512-parisc.o",
rc4_obj => "rc4-parisc.o",
modes_obj => "ghash-parisc.o",
perlasm_scheme => "32"
},
parisc20_64_asm => {
template => 1,
inherit_from => [ "parisc11_asm" ],
bn_obj => sub { my $r=join(" ",@_); $r=~s/bn_asm/pa-risc2W/; $r; },
perlasm_scheme => "64",
},
ppc64_asm => {
template => 1,
cpuid_obj => "ppccpuid.o ppccap.o",
bn_obj => "bn-ppc.o ppc-mont.o ppc64-mont.o",
aes_obj => "aes_core.o aes_cbc.o aes-ppc.o vpaes-ppc.o aesp8-ppc.o",
sha1_obj => "sha1-ppc.o sha256-ppc.o sha512-ppc.o sha256p8-ppc.o sha512p8-ppc.o",
modes_obj => "ghashp8-ppc.o",
},
ppc32_asm => {
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>
8 years ago
inherit_from => [ "ppc64_asm" ],
template => 1
},
);
{ my $no_asm_templates=0;
foreach (@ARGV) { $no_asm_templates=1 if (/^\-?no\-asm$/); }
sub asm { $no_asm_templates?():@_; }
}
sub stringtohash {
my $in = shift @_;
if (ref($in) eq "HASH") {
return $in;
}
my @stringsequence = (
"cc",
"cflags",
"unistd",
"thread_cflag",
"sys_id",
"lflags",
"bn_ops",
"cpuid_obj",
"bn_obj",
"ec_obj",
"des_obj",
"aes_obj",
"bf_obj",
"md5_obj",
"sha1_obj",
"cast_obj",
"rc4_obj",
"rmd160_obj",
"rc5_obj",
"wp_obj",
"cmll_obj",
"modes_obj",
"engines_obj",
"perlasm_scheme",
"dso_scheme",
"shared_target",
"shared_cflag",
"shared_ldflag",
"shared_extension",
"ranlib",
"arflags",
"multilib",
);
# return a ref to a hash, that's what the outer braces are for.
return { map { shift @stringsequence => $_ } split /:/, $in };
};
# Read configuration target stanzas from a file, so that people can have
# local files with their own definitions
sub read_config {
my $fname = shift;
open(CONFFILE, "< $fname")
or die "Can't open configuration file '$fname'!\n";
my $x = $/;
undef $/;
my $content = <CONFFILE>;
$/ = $x;
close(CONFFILE);
my %targets = ();
eval $content;
# Make sure we have debug- targets first
my @keys =
sort {
my $a_nd = $a =~ m/^debug-/ ? $' :$a;
my $b_nd = $b =~ m/^debug-/ ? $' :$b;
my $res = 0;
if (($a_nd == $a) == ($b_nd == $b)) {
# they are both debug- or not, compare them as they are
$res = $a cmp $b;
} elsif ($a_nd != $a) {
# $a is debug-, make it lesser
$res = -1;
} else {
# $b is debug-, make $a greater
$res = 1;
}
$res;
} keys %targets;
foreach (@keys) {
if (ref($targets{$_}) ne "HASH") {
# Value is assumed to be a string. Split it up to
# become a hash table of parameters. Also, try to
# merge debug- variants with the non-debug target.
# Start with converting the value from a string to a
# standardised hash of fields. Using $tohash is safe,
# if the input is already a hash ref, it's just returned
# back.
$targets{$_} = stringtohash($targets{$_});
# If the current target is a debug target, there might
# be a corresponding non-debug target that we can merge
# with. If it isn't a debug- target, we've already done
# as much merging as we can and do not need to bother
# with that any more.
if ($_ =~ m/^debug-/) {
my $debugkey = $_;
my $nondebugkey = $';
my $debug = $targets{$debugkey};
my $nondebug;
if ($targets{$nondebugkey}) {
$nondebug = stringtohash($targets{$nondebugkey});
}
if ($nondebug) {
# There's both a debug and non-debug variant of
# this target, so we should try to merge them
# together.
# First, check that the non-debug variant isn't
# already built up with all it should have.
if ($nondebug->{debug_cflags}
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>
8 years ago
|| $nondebug->{release_cflags}
|| $nondebug->{debug_lflags}
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>
8 years ago
|| $nondebug->{release_lflags}) {
warn "there's a debug target $debugkey to be merged with a target $nondebugkey, but the latter seems to already have both nodebug and debug information. This requires human intervention. Skipping $debugkey...";
next;
}
# Now, check similarity.
# For keys they have in common, support that
# cflags and lflags can differ, otherwise they
# must have exactly the same values for them
# to be merged into one.
my $similarenough = 1;
for (keys %{$debug}) {
if ($nondebug->{$_} ne $debug->{$_}
&& $_ !~ m/^[cl]flags$/) {
$similarenough = 0;
last;
}
}
if ($similarenough) {
# Here's where the magic happens, split the
# options in the debug and non-debug variants
# cflags and ldflags into three strings each,
# one with common flags, one with extra debug
# flags and one with extra non-debug flags.
# The result ends up in %h_nondebug, which
# becomes the merged variant when we're done.
# for each of cflags and lflags, they are
# replaced with cflags, debug_cflags,
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>
8 years ago
# release_cflags and similar for lflags.
#
# The purpose is that 'cflags' should be
# used together with 'debug_cflags' or
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>
8 years ago
# 'release_cflags' depending on what the
# user asks for.
foreach (("cflags", "lflags")) {
my @list_d = split /\s+/, $debug->{$_};
my @list_nd = split /\s+/, $nondebug->{$_};
my %presence = (); # bitmap
# 1: present in @list_d
# 2: present in @list_nd
# 3: present in both
map { $presence{$_} += 1; } @list_d;
map { $presence{$_} += 2; } @list_nd;
delete $nondebug->{$_};
# Note: we build from the original lists to
# preserve order, it might be important
$nondebug->{"debug-".$_} =
join(" ",
grep { $presence{$_} == 1 } @list_d);
$nondebug->{"nodebug-".$_} =
join(" ",
grep { $presence{$_} == 2 } @list_nd);
$nondebug->{$_} =
join(" ",
grep { $presence{$_} == 3 } @list_d);
}
$targets{$nondebugkey} = $nondebug;
delete $targets{$debugkey};
}
}
}
}
}
%table = (%table, %targets);
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>
8 years ago
# Local function to resolve inheritance
my $resolve_inheritance;
$resolve_inheritance =
sub {
my $target = shift;
my @breadcrumbs = @_;
if (grep { $_ eq $target } @breadcrumbs) {
die "inherit_from loop! target backtrace:\n "
,$target,"\n ",join("\n ", @breadcrumbs),"\n";
}
# Recurse through all inheritances. They will be resolved on
# the fly, so when this operation is done, they will all just
# be a bunch of attributes with string values.
# What we get here, though, are keys with references to lists
# of the combined values of them all. We will deal with lists
# after this stage is done.
my %combined_inheritance = ();
if ($table{$target}->{inherit_from}) {
foreach (@{$table{$target}->{inherit_from}}) {
my %inherited_config =
$resolve_inheritance->($_, $target, @breadcrumbs);
# 'template' is a marker that's considered private to
# the config that had it.
delete $inherited_config{template};
map {
if (!$combined_inheritance{$_}) {
$combined_inheritance{$_} = [];
}
push @{$combined_inheritance{$_}}, $inherited_config{$_};
} keys %inherited_config;
}
}
# We won't need inherit_from in this target any more, since
# we've resolved all the inheritances that lead to this
delete $table{$target}->{inherit_from};
# Now is the time to deal with those lists. Here's the place
# to decide what shall be done with those lists, all based on
# the values of the target we're currently dealing with.
# - If a value is a coderef, it will be executed with the list
# of inherited values as arguments.
# - If the corresponding key doesn't have a value at all or is
# the emoty string, the inherited value list will be run
# through the default combiner (below), and the result
# becomes this target's value.
# - Otherwise, this target's value is assumed to be a string
# that will simply override the inherited list of values.
my $default_combiner = sub { join(' ',@_) };
my %all_keys =
map { $_ => 1 } (keys %combined_inheritance,
keys %{$table{$target}});
foreach (sort keys %all_keys) {
# Current target doesn't have a value for the current key?
# Assign it the default combiner, the rest of this loop
# body will handle it just like any other coderef.
if (!exists $table{$target}->{$_}) {
$table{$target}->{$_} = $default_combiner;
}
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>
8 years ago
my $valuetype = ref($table{$target}->{$_});
if ($valuetype eq "CODE") {
# CODE reference, execute it with the inherited values
# as arguments.
$table{$target}->{$_} =
$table{$target}->{$_}->(@{$combined_inheritance{$_}});
} elsif ($valuetype eq "") {
# Scalar, just leave it as is.
} else {
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>
8 years ago
# Some other type of reference that we don't handle.
# Better to abort at this point.
die "cannot handle reference type $valuetype,"
," found in target $target -> $_\n";
}
}
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>
8 years ago
# Finally done, return the result.
%{$table{$target}};
};
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>
8 years ago
# Go through all new targets and resolve inheritance and template
# references.
foreach (keys %targets) {
# We're ignoring the returned values here, they are only valuable
# to the inner recursion of this function.
$resolve_inheritance->($_);
}
}
my ($vol, $dir, $dummy) = File::Spec->splitpath($0);
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>
8 years ago
my $pattern = File::Spec->catpath($vol, $dir, "Configurations/*.conf");
foreach (sort glob($pattern) ) {
&read_config($_);
}
my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A
debug-VC-WIN64I debug-VC-WIN64A
VC-NT VC-CE VC-WIN32 debug-VC-WIN32
BC-32
netware-clib netware-clib-bsdsock
netware-libc netware-libc-bsdsock);
my $prefix="";
my $libdir="";
my $openssldir="";
my $exe_ext="";
my $install_prefix= "$ENV{'INSTALL_PREFIX'}";
my $cross_compile_prefix="";
my $fipslibdir="/usr/local/ssl/fips-2.0/lib/";
my $nofipscanistercheck=0;
my $baseaddr="0xFB00000";
my $no_threads=0;
my $threads=0;
my $no_shared=0; # but "no-shared" is default
my $zlib=1; # but "no-zlib" is default
my $no_rfc3779=0;