wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
openssl/Configure

2634 lines
84 KiB
Text
Raw Normal View History

Drop the old perl start magic and replace it with a normal shebang perlrun(1) leads the way. Reviewed-by: Matt Caswell <matt@openssl.org>
2015-11-24 13:06:45 +00:00
#! /usr/bin/env perl
Add perl modeline to Configure scripts Encourages GitHub to perform proper syntax highlighting. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-24 05:44:58 +00:00
# -*- mode: perl; -*-
Copyright consolidation; .pm and Configure Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-20 14:20:59 +00:00
# Copyright 2016 The OpenSSL Project Authors. All Rights Reserved.
#
# Licensed under the OpenSSL license (the "License"). You may not use
# this file except in compliance with the License. You can obtain a copy
# in the file LICENSE in the source distribution or at
# https://www.openssl.org/source/license.html
Drop the old perl start magic and replace it with a normal shebang perlrun(1) leads the way. Reviewed-by: Matt Caswell <matt@openssl.org>
2015-11-24 13:06:45 +00:00
Don't hard-code path to Perl interpreter on shebang line of Configure script. Instead use the usual Shell->Perl transition trick.
1999-02-25 08:48:52 +00:00
## Configure -- OpenSSL source tree configuration script
Add strictness, fix variable substition bugs.
1998-12-28 17:08:48 +00:00
Enforce the demand for Perl 5.10.0 as a minimum. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 09:03:14 +00:00
require 5.10.0;
Add strictness, fix variable substition bugs.
1998-12-28 17:08:48 +00:00
use strict;
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>
2015-02-24 22:40:22 +00:00
use File::Basename;
Use a simpler method to build a glob than splitpath and catpath It turns out that the combination splitpath() could return an empty string for the directory part. This doesn't play well with catdir(). Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-02 18:47:05 +00:00
use File::Spec::Functions qw/:DEFAULT abs2rel rel2abs/;
Use File::Path::mkpath rather than File::Path::make_path File::Path::make_path didn't show up before File::Path 2.06 / perl v5.10.1. Because we're trying to stay compatible with perl v5.10.0 and up, it's better to use the legacy interface. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-08 15:27:15 +00:00
use File::Path qw/mkpath/;
Configure,test/recipes: "pin" glob to File::Glob::glob. As it turns out default glob's behaviour for quoted argument varies from version to version, making it impossible to Configure or run tests in some cases. The reason for quoting globs was to accommodate source path with spaces in its name, which was treated by default glob as multiple paths. File::Glob::glob on the other hand doesn't consider spaces as delimiters and therefore works with unquoted patterns. [Unfortunaltely File::Glob::glob, being too csh-ly, doesn't work on VMS, hence the "pinning" is conditional.] Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-28 14:11:01 +00:00
if ($^O ne "VMS") {
use File::Glob qw/glob/;
}
Add strictness, fix variable substition bugs.
1998-12-28 17:08:48 +00:00
Defunct assembler files removed; various cleanups. New Ultrix and Alpha entries submitted by Bernhard Simon <simon@zid.tuwien.ac.at>.
1999-04-19 13:54:11 +00:00
# see INSTALL for instructions.
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
my $usage="Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-egd] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--config=FILE] os/compiler[:flags]\n";
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
Document additional Configure flags.
1999-04-19 15:19:58 +00:00
# Options:
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-29 21:52:08 +00:00
#
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>
2015-02-24 22:40:22 +00:00
# --config add the given configuration file, which will be read after
# any "Configurations*" files that are found in the same
# directory as this script.
Refresh the thinking of --prefix and --openssldir --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>
2016-01-20 17:11:51 +00:00
# --prefix prefix for the OpenSSL installation, which includes the
# directories bin, lib, include, share/man, share/doc/openssl
# This becomes the value of INSTALLTOP in Makefile
# (Default: /usr/local)
# --openssldir OpenSSL data area, such as openssl.cnf, certificates and keys.
# If it's a relative directory, it will be added on the directory
# given with --prefix.
# This becomes the value of OPENSSLDIR in Makefile and in C.
# (Default: PREFIX/ssl)
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-29 21:52:08 +00:00
#
Rudimentary support for cross-compiling.
2006-10-21 13:38:16 +00:00
# --cross-compile-prefix Add specified prefix to binutils components.
#
Backwards-compatibility subject to OPENSSL_API_COMPAT Provide backwards-compatiblity for functions, macros and include files if OPENSSL_API_COMPAT is either not defined or defined less than the version number of the release in which the feature was deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-05 04:00:33 +00:00
# --api One of 0.9.8, 1.0.0 or 1.1.0. Do not compile support for
# interfaces deprecated as of the specified OpenSSL version.
#
Merge the engine branch into the main trunk. All conflicts resolved. At the same time, add VMS support for Rijndael.
2000-10-26 21:07:28 +00:00
# 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.
New Configure options "threads" and "no-threads". For Solaris and Linux, "threads" (with proper compiler options) is the default. Submitted by: Reviewed by: PR:
1999-04-29 16:10:09 +00:00
# [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)
Added and corrected documentation for the 'shared' option
2000-08-02 04:19:50 +00:00
# [no-]shared [don't] try to create shared libraries when supported.
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
# [no-]pic [don't] try to build position independent code when supported.
Fix a few typos Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 14:57:25 +00:00
# If disabled, it also disables shared and dynamic-engine.
Error in comment.
1999-04-19 14:55:56 +00:00
# no-asm do not use assembler
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
# no-dso do not compile in any native shared-library methods. This
# will ensure that all methods just return NULL.
Add a no-egd option to disable EGD-related code The entropy-gathering daemon is used only on a small number of machines. Provide a configure knob so that EGD support can be disabled by default but re-enabled on those systems that do need it. Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
2016-01-13 00:02:16 +00:00
# no-egd do not compile support for the entropy-gathering daemon APIs
Add the possibility to specify the use of zlib compression and decompression. It can be set up to link at link time or to load the zlib library at run-time.
2001-07-12 09:11:14 +00:00
# [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.
PR: 2535 Submitted by: Robin Seggelmann <seggelmann@fh-muenster.de> Reviewed by: steve Add SCTP support for DTLS (RFC 6083).
2011-12-25 14:45:15 +00:00
# sctp include SCTP support
Defunct assembler files removed; various cleanups. New Ultrix and Alpha entries submitted by Bernhard Simon <simon@zid.tuwien.ac.at>.
1999-04-19 13:54:11 +00:00
# 386 generate 80386 code
Don't build RC4 ciphersuites into libssl by default RC4 based ciphersuites in libssl have been disabled by default. They can be added back by building OpenSSL with the "enable-weak-ssl-ciphers" Configure option at compile time. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 15:40:51 +00:00
# enable-weak-ssl-ciphers
# Enable weak ciphers that are disabled by default. This currently
# only includes RC4 based ciphers.
Add anchors for AES, SHA-256/-512 assembler modules and SSE2 code pathes. I also used this opportunity to clean up some out-of-date targets and re-group targets by OS.
2004-07-18 16:19:34 +00:00
# no-sse2 disables IA-32 SSE2 code, above option implies no-sse2
New Configure option no-<cipher> (rsa, idea, rc5, ...).
1999-04-27 03:19:12 +00:00
# no-<cipher> build without specified algorithm (rsa, idea, rc5, ...)
Strip trailing whitespace from Configure.
2014-05-26 16:19:28 +00:00
# -<xxx> +<xxx> compiler options are passed through
This change will cause builds (by default) to not use different STACK structures and functions for each stack type. The previous behaviour can be enabled by configuring with the "-DDEBUG_SAFESTACK" option. This will also cause "make update" (mkdef.pl in particular) to update the libeay.num and ssleay.num symbol tables with the number of extra functions DEBUG_SAFESTACK creates. The way this change works is to accompany each DECLARE_STACK_OF() macro with a set of "#define"d versions of the sk_##type##_*** functions that ensures all the existing "type-safe" stack calls are precompiled into the underlying stack calls. The presence or abscence of the DEBUG_SAFESTACK symbol controls whether this block of "#define"s or the DECLARE_STACK_OF() macro is taking effect. The block of "#define"s is in turn generated and maintained by a perl script (util/mkstack.pl) that encompasses the block with delimiting C comments. This works in a similar way to the auto-generated error codes and, like the other such maintenance utilities, is invoked by the "make update" target. A long (but mundane) commit will follow this with the results of "make update" - this will include all the "#define" blocks for each DECLARE_STACK_OF() statement, along with stripped down libeay.num and ssleay.num files.
2000-06-01 05:13:52 +00:00
#
# 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.
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
# BN_LLONG use the type 'long long' in crypto/bn/bn.h
# RC4_CHAR use 'char' instead of 'int' for RC4_INT in crypto/rc4/rc4.h
Add anchors for AES, SHA-256/-512 assembler modules and SSE2 code pathes. I also used this opportunity to clean up some out-of-date targets and re-group targets by OS.
2004-07-18 16:19:34 +00:00
# Following are set automatically by this script
#
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# MD5_ASM use some extra md5 assembler,
# SHA1_ASM use some extra sha1 assembler, must define L_ENDIAN for x86
# RMD160_ASM use some extra ripemd160 assembler,
Add anchors for AES, SHA-256/-512 assembler modules and SSE2 code pathes. I also used this opportunity to clean up some out-of-date targets and re-group targets by OS.
2004-07-18 16:19:34 +00:00
# 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
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
Add a set of standard gcc warning options which are designed to be the minimum requirement for committed code. Added to debug-steve* config targets for now.
2009-01-11 15:56:32 +00:00
# Minimum warning options... any contributions to OpenSSL should at least get
Strip trailing whitespace from Configure.
2014-05-26 16:19:28 +00:00
# past these.
Add a set of standard gcc warning options which are designed to be the minimum requirement for committed code. Added to debug-steve* config targets for now.
2009-01-11 15:56:32 +00:00
Clean-up *_DEBUG options. Since NDEBUG is defined unconditionally on command line for release builds, we can omit *_DEBUG options in favour of effective "all-on" in debug builds exercised though CI. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-04-06 10:47:35 +00:00
# DEBUG_UNUSED enables __owur (warn unused result) checks.
my $gcc_devteam_warn = "-DDEBUG_UNUSED"
# -DPEDANTIC complements -pedantic and is meant to mask code that
# is not strictly standard-compliant and/or implementation-specifc,
# e.g. inline assembly, disregards to alignment requirements, such
# that -pedantic would complain about. Incidentally -DPEDANTIC has
# to be used even in sanitized builds, because sanitizer too is
# supposed to and does take notice of non-standard behaviour. Then
# -pedantic with pre-C9x compiler would also complain about 'long
# long' not being supported. As 64-bit algorithms are common now,
# it grew impossible to resolve this without sizeable additional
# code, so we just tell compiler to be pedantic about everything
# but 'long long' type.
. " -DPEDANTIC -pedantic -Wno-long-long"
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-13 17:27:11 +00:00
. " -Wall"
. " -Wsign-compare"
. " -Wmissing-prototypes"
. " -Wshadow"
. " -Wformat"
. " -Wtype-limits"
. " -Werror"
;
Add a set of standard gcc warning options which are designed to be the minimum requirement for committed code. Added to debug-steve* config targets for now.
2009-01-11 15:56:32 +00:00
Fix build on MacOS. Reviewed-by: Andy Polyakov
2015-04-19 13:10:54 +00:00
# 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
Add -Wconditional-uninitialized to clang strict warnings. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-08-02 01:45:44 +00:00
# following warnings can also be enabled:
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-13 17:27:11 +00:00
# -Wswitch-enum
# -Wcast-align
# -Wunreachable-code
Remove unused parameters from internal functions Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 03:33:56 +00:00
# -Wlanguage-extension-token -- no, we use asm()
# -Wunused-macros -- no, too tricky for BN and _XOPEN_SOURCE etc
# -Wextended-offsetof -- no, needed in CMS ASN1 code
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-13 17:27:11 +00:00
my $clang_devteam_warn = ""
. " -Qunused-arguments"
. " -Wextra"
. " -Wno-unused-parameter"
. " -Wno-missing-field-initializers"
. " -Wno-language-extension-token"
. " -Wno-extended-offsetof"
. " -Wconditional-uninitialized"
. " -Wincompatible-pointer-types-discards-qualifiers"
. " -Wmissing-variable-declarations"
;
Add a clang build target for linux-x86_64 This change documents the world as-is, by turning all warnings on, and then turning warnings that trigger off again. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-05 12:46:26 +00:00
Make the use of mdebug backtrace a separate option To force it on anyone using --strict-warnings was the wrong move, as this is an option best left to those who know what they're doing. Use with care! Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-14 11:16:52 +00:00
# This adds backtrace information to the memory leak info. Is only used
# when crypto-mdebug-backtrace is enabled.
my $memleak_devteam_backtrace = "-rdynamic";
Move the backtrace memleak options to a separate variable The contents of this variable ($memleak_devteam_backtrace) is added to $cflags unless we build for a platform we know doesn't support gcc's -rdynamic och backtrace() and friends. Reviewed-by: Andy Polyakov <appro@openssl.org>
2015-12-02 17:44:26 +00:00
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
my $strict_warnings = 0;
Fold a bunch of linux and *BSD targets into [linux|BSD]-generic[32|64]. Idea is to provide unified "fall-down" case for all rare platforms out there. ./config is free to enable some optimizations, such as endianness specification, specific -mcpu flags...
2005-01-24 14:38:14 +00:00
# As for $BSDthreads. Idea is to maintain "collective" set of flags,
Strip trailing whitespace from Configure.
2014-05-26 16:19:28 +00:00
# which would cover all BSD flavors. -pthread applies to them all,
Fold a bunch of linux and *BSD targets into [linux|BSD]-generic[32|64]. Idea is to provide unified "fall-down" case for all rare platforms out there. ./config is free to enable some optimizations, such as endianness specification, specific -mcpu flags...
2005-01-24 14:38:14 +00:00
# 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?
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
our $BSDthreads="-pthread -D_THREAD_SAFE -D_REENTRANT";
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
Backwards-compatibility subject to OPENSSL_API_COMPAT Provide backwards-compatiblity for functions, macros and include files if OPENSSL_API_COMPAT is either not defined or defined less than the version number of the release in which the feature was deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-05 04:00:33 +00:00
#
# API compability name to version number mapping.
#
my $maxapi = "1.1.0"; # API for "no-deprecated" builds
my $apitable = {
"1.1.0" => "0x10100000L",
"1.0.0" => "0x10000000L",
"0.9.8" => "0x00908000L",
};
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
our %table = ();
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
our %config = ();
Configure - move the addition of the zlib / libz lib to configs 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>
2016-02-27 10:37:33 +00:00
our %withargs = ();
Add the configuration target VxWorks.
2002-02-14 15:37:38 +00:00
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# Forward declarations ###############################################
Configure: fold related configurations more aggressively and clean-up. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-03-16 21:33:36 +00:00
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# read_config(filename)
#
# Reads a configuration file and populates %table with the contents
# (which the configuration file places in %targets).
sub read_config;
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>
2015-03-06 09:01:08 +00:00
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# resolve_config(target)
#
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# Resolves all the late evaluations, inheritances and so on for the
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# chosen target and any target it inherits from.
sub resolve_config;
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>
2015-03-06 09:01:08 +00:00
Update from 1.0.0-stable
2009-07-01 11:46:03 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
# Information collection #############################################
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# Unified build supports separate build dir
Use rel2abs() on VMS, rather than realpath() It seems realpath() is quite buggy on VMS, or will at least give quite surprising results. On the other hand, realpath() is the better on Unix to clean out clutter like foo/../bar on Unix. So we make out own function to get the absolute directory for a given input, and use rel2abs() or realpath() depending on the platform Configure runs on. Issue reported by Steven M. Schweda <sms@antinode.info> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-09 09:15:13 +00:00
my $srcdir = catdir(absolutedir(dirname($0))); # catdir ensures local syntax
my $blddir = catdir(absolutedir(".")); # catdir ensures local syntax
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $dofile = abs2rel(catfile($srcdir, "util/dofile.pl"));
Add the possibility to have an extra local OpenSSL configs directory The environment variable OPENSSL_LOCAL_CONFIG_DIR is used to indicate that there's a local directory with extra configuration files. Reviewed-by: Stephen Henson <steve@openssl.org>
2016-05-02 14:50:51 +00:00
my $local_config_envname = 'OPENSSL_LOCAL_CONFIG_DIR';
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$config{sourcedir} = abs2rel($srcdir);
$config{builddir} = abs2rel($blddir);
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
# Collect version numbers
$config{version} = "unknown";
$config{version_num} = "unknown";
$config{shlib_version_number} = "unknown";
$config{shlib_version_history} = "unknown";
collect_information(
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
collect_from_file(catfile($srcdir,'include/openssl/opensslv.h')),
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
qr/OPENSSL.VERSION.TEXT.*OpenSSL (\S+) / => sub { $config{version} = $1; },
qr/OPENSSL.VERSION.NUMBER.*(0x\S+)/ => sub { $config{version_num}=$1 },
qr/SHLIB_VERSION_NUMBER *"([^"]+)"/ => sub { $config{shlib_version_number}=$1 },
qr/SHLIB_VERSION_HISTORY *"([^"]*)"/ => sub { $config{shlib_version_history}=$1 }
);
if ($config{shlib_version_history} ne "") { $config{shlib_version_history} .= ":"; }
($config{major}, $config{minor})
= ($config{version} =~ /^([0-9]+)\.([0-9\.]+)/);
($config{shlib_major}, $config{shlib_minor})
= ($config{shlib_version_number} =~ /^([0-9]+)\.([0-9\.]+)/);
die "erroneous version information in opensslv.h: ",
"$config{major}, $config{minor}, $config{shlib_major}, $config{shlib_minor}\n"
if ($config{major} eq "" || $config{minor} eq ""
|| $config{shlib_major} eq "" || $config{shlib_minor} eq "");
# Collect target configurations
Use a simpler method to build a glob than splitpath and catpath It turns out that the combination splitpath() could return an empty string for the directory part. This doesn't play well with catdir(). Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-02 18:47:05 +00:00
my $pattern = catfile(dirname($0), "Configurations", "*.conf");
Configure,test/recipes: "pin" glob to File::Glob::glob. As it turns out default glob's behaviour for quoted argument varies from version to version, making it impossible to Configure or run tests in some cases. The reason for quoting globs was to accommodate source path with spaces in its name, which was treated by default glob as multiple paths. File::Glob::glob on the other hand doesn't consider spaces as delimiters and therefore works with unquoted patterns. [Unfortunaltely File::Glob::glob, being too csh-ly, doesn't work on VMS, hence the "pinning" is conditional.] Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-28 14:11:01 +00:00
foreach (sort glob($pattern)) {
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>
2015-02-24 22:40:22 +00:00
&read_config($_);
}
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
Add the possibility to have an extra local OpenSSL configs directory The environment variable OPENSSL_LOCAL_CONFIG_DIR is used to indicate that there's a local directory with extra configuration files. Reviewed-by: Stephen Henson <steve@openssl.org>
2016-05-02 14:50:51 +00:00
if (defined $ENV{$local_config_envname}) {
if ($^O eq 'VMS') {
# VMS environment variables are logical names,
# which can be used as is
$pattern = $local_config_envname . ':' . '*.conf';
} else {
$pattern = catfile($ENV{$local_config_envname}, '*.conf');
}
Configure,test/recipes: "pin" glob to File::Glob::glob. As it turns out default glob's behaviour for quoted argument varies from version to version, making it impossible to Configure or run tests in some cases. The reason for quoting globs was to accommodate source path with spaces in its name, which was treated by default glob as multiple paths. File::Glob::glob on the other hand doesn't consider spaces as delimiters and therefore works with unquoted patterns. [Unfortunaltely File::Glob::glob, being too csh-ly, doesn't work on VMS, hence the "pinning" is conditional.] Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-28 14:11:01 +00:00
foreach (sort glob($pattern)) {
Add the possibility to have an extra local OpenSSL configs directory The environment variable OPENSSL_LOCAL_CONFIG_DIR is used to indicate that there's a local directory with extra configuration files. Reviewed-by: Stephen Henson <steve@openssl.org>
2016-05-02 14:50:51 +00:00
&read_config($_);
}
}
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
print "Configuring OpenSSL version $config{version} (0x$config{version_num})\n";
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
$config{prefix}="";
$config{openssldir}="";
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
$config{processor}="";
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{libdir}="";
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
$config{cross_compile_prefix}="";
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/";
Add fipscanisterbuild configuration option and update Makefile.org: doesn't compile yet
2011-01-26 12:31:30 +00:00
my $nofipscanistercheck=0;
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{baseaddr}="0xFB00000";
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
my $auto_threads=1; # enable threads automatically? true by default
Workaround for solaris64 linking problem (explicit "ar rs" is needed to create a symbol table). Sun patches such as 109147-06 probably fix this problem, but we can easily avoid it.
2001-03-09 13:04:06 +00:00
my $default_ranlib;
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{fips}=0;
# Top level directories to build
$config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "tools" ];
# crypto/ subdirectories to build
$config{sdirs} = [
"objects",
Add blake2 support. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 22:08:31 +00:00
"md2", "md4", "md5", "sha", "mdc2", "hmac", "ripemd", "whrlpool", "poly1305", "blake2",
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
"des", "aes", "rc2", "rc4", "rc5", "idea", "bf", "cast", "camellia", "seed", "chacha", "modes",
"bn", "ec", "rsa", "dsa", "dh", "dso", "engine",
"buffer", "bio", "stack", "lhash", "rand", "err",
"evp", "asn1", "pem", "x509", "x509v3", "conf", "txt_db", "pkcs7", "pkcs12", "comp", "ocsp", "ui",
Remove JPAKE Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-02-14 05:17:59 +00:00
"cms", "ts", "srp", "cmac", "ct", "async", "kdf"
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
];
New Makefile variables $(RANLIB) and $(PERL).
1999-04-01 12:34:33 +00:00
Support disabling any or all TLS or DTLS versions Some users want to disable SSL 3.0/TLS 1.0/TLS 1.1, and enable just TLS 1.2. In the future they might want to disable TLS 1.2 and enable just TLS 1.3, ... This commit makes it possible to disable any or all of the TLS or DTLS protocols. It also considerably simplifies the SSL/TLS tests, by auto-generating the min/max version tests based on the set of supported protocols (425 explicitly written out tests got replaced by two loops that generate all 425 tests if all protocols are enabled, fewer otherwise). Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-18 18:10:21 +00:00
# Known TLS and DTLS protocols
my @tls = qw(ssl3 tls1 tls1_1 tls1_2);
my @dtls = qw(dtls1 dtls1_2);
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# Explicitly known options that are possible to disable. They can
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
# be regexps, and will be used like this: /^no-${option}$/
# For developers: keep it sorted alphabetically
my @disablables = (
Disable afalg when engine is disabled. Also make it possible to disable afalg separately. we still need to update config again Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-14 11:21:44 +00:00
"afalgeng",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
"asan",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"asm",
Add option to disable async Add no-async option to Configure that forces ASYNC_NULL. Related to RT1979 An embedded system or replacement C library (e.g. musl or uClibc) may not support the *context APIs that are needed for async operation. Compiles with musl. Ran unit tests, async tests skipped as expected. Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-04 16:41:25 +00:00
"async",
Provide framework for auto initialise/deinitialise of the library This commit provides the basis and core code for an auto initialisation and deinitialisation framework for libcrypto and libssl. The intention is to remove the need (in many circumstances) to call explicit initialise and deinitialise functions. Explicit initialisation will still be an option, and if non-default initialisation is needed then it will be required. Similarly for de-initialisation (although this will be a lot easier since it will bring all de-initialisation into a single function). Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-09 11:26:14 +00:00
"autoalginit",
Add an OPENSSL_NO_AUTOERRINIT option This option disables automatic loading of the crypto/ssl error strings in order to keep statically linked executable file size down Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-09 09:39:07 +00:00
"autoerrinit",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"bf",
Add blake2 support. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 22:08:31 +00:00
"blake2",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"camellia",
"capieng",
"cast",
Configure: make no-chacha and no-poly1305 work. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-09 22:02:11 +00:00
"chacha",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"cmac",
"cms",
"comp",
Adds crypto-mdebug as a valid option Adds crypto-mdebug as a valid option. Fixes https://github.com/openssl/openssl/issues/537 Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-09 22:55:57 +00:00
"crypto-mdebug",
Make the use of mdebug backtrace a separate option To force it on anyone using --strict-warnings was the wrong move, as this is an option best left to those who know what they're doing. Use with care! Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-14 11:16:52 +00:00
"crypto-mdebug-backtrace",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"ct",
"deprecated",
"des",
"dgram",
"dh",
"dsa",
"dso",
Use OPENSSL_NO_DTLS instead of OPENSSL_NO_DTLS1 Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-12 10:12:22 +00:00
"dtls",
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
"dynamic-engine",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"ec",
"ec2m",
Support disabling any or all TLS or DTLS versions Some users want to disable SSL 3.0/TLS 1.0/TLS 1.1, and enable just TLS 1.2. In the future they might want to disable TLS 1.2 and enable just TLS 1.3, ... This commit makes it possible to disable any or all of the TLS or DTLS protocols. It also considerably simplifies the SSL/TLS tests, by auto-generating the min/max version tests based on the set of supported protocols (425 explicitly written out tests got replaced by two loops that generate all 425 tests if all protocols are enabled, fewer otherwise). Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-18 18:10:21 +00:00
"ecdh",
"ecdsa",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"ec_nistp_64_gcc_128",
If egd is disabled by default, it should be possible to enable Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-03 20:08:17 +00:00
"egd",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"engine",
RT4310: Fix varous no-XXX builds When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing. This prevents md_rand.c from failing to build. Probably better to do it this way than to wrap every instance in an explicit #ifdef. A bunch of new socket code got added to a new file crypto/bio/b_addr.c. Make it all go away if OPENSSL_NO_SOCK is defined. Allow configuration with no-ripemd, no-ts, no-ui We use these for the UEFI build. Also remove the 'Really???' comment from no-err and no-locking. We use those too. We need to drop the crypto/engine directory from the build too, and also set OPENSSL_NO_ENGINE Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-02-17 18:33:51 +00:00
"err",
RT3628: Allow filenames to be eliminated from compiled library Although I explicitly don't care about the tinfoil-hat reason given in the initial opening of RT#3628, that "paths usually contain private information", there *are* situations where it's useful to eliminate the filenames from the compiled binary. The two reasons we do care about in the context of firmware such as EDK2 are that it allows for a smaller footprint, and it is also a necessary component of a binary-reproducible build. To that end, introduce OPENSSL_FILE and OPENSSL_LINE macros, defining them to __FILE__ and __LINE__ respectively in the normal case, but to "" and 0 when OPENSSL_NO_FILENAMES is set. This is mostly a naïve invocation of $ sed 's/__\([FL]I[NL]E\)__/OPENSSL_\1/g' -i `git grep -l __LINE__` but with a few instances change to just print the function name instead (although those probably need to die anyway) and test cases left untouched. Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-07-30 10:45:25 +00:00
"filenames",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
"fuzz",
Fix no-gost Configure had the wrong name for the no-gost option. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-21 15:04:08 +00:00
"gost",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"heartbeats",
"hw(-.+)?",
"idea",
Add the configure option 'no-makedepend' If no makedepend program or equaly capable compiler is present, 'makedepend' gets disabled automatically. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 00:14:29 +00:00
"makedepend",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"md2",
"md4",
"mdc2",
Fix building without multiblock support Not all platforms support multiblock. Building without it fails prior to this fix. RT#4396 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-07 23:26:32 +00:00
"multiblock",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"nextprotoneg",
"ocb",
"ocsp",
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
"pic",
Configure: make no-chacha and no-poly1305 work. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-09 22:02:11 +00:00
"poly1305",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"posix-io",
"psk",
"rc2",
"rc4",
"rc5",
"rdrand",
"rfc3779",
RT4310: Fix varous no-XXX builds When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing. This prevents md_rand.c from failing to build. Probably better to do it this way than to wrap every instance in an explicit #ifdef. A bunch of new socket code got added to a new file crypto/bio/b_addr.c. Make it all go away if OPENSSL_NO_SOCK is defined. Allow configuration with no-ripemd, no-ts, no-ui We use these for the UEFI build. Also remove the 'Really???' comment from no-err and no-locking. We use those too. We need to drop the crypto/engine directory from the build too, and also set OPENSSL_NO_ENGINE Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-02-17 18:33:51 +00:00
"ripemd",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"rmd160",
"scrypt",
"sctp",
"seed",
"shared",
"sock",
"srp",
"srtp",
"sse2",
"ssl",
"ssl-trace",
"static-engine",
"stdio",
"threads",
"tls",
RT4310: Fix varous no-XXX builds When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing. This prevents md_rand.c from failing to build. Probably better to do it this way than to wrap every instance in an explicit #ifdef. A bunch of new socket code got added to a new file crypto/bio/b_addr.c. Make it all go away if OPENSSL_NO_SOCK is defined. Allow configuration with no-ripemd, no-ts, no-ui We use these for the UEFI build. Also remove the 'Really???' comment from no-err and no-locking. We use those too. We need to drop the crypto/engine directory from the build too, and also set OPENSSL_NO_ENGINE Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-02-17 18:33:51 +00:00
"ts",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
"ubsan",
RT4310: Fix varous no-XXX builds When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing. This prevents md_rand.c from failing to build. Probably better to do it this way than to wrap every instance in an explicit #ifdef. A bunch of new socket code got added to a new file crypto/bio/b_addr.c. Make it all go away if OPENSSL_NO_SOCK is defined. Allow configuration with no-ripemd, no-ts, no-ui We use these for the UEFI build. Also remove the 'Really???' comment from no-err and no-locking. We use those too. We need to drop the crypto/engine directory from the build too, and also set OPENSSL_NO_ENGINE Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-02-17 18:33:51 +00:00
"ui",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"unit-test",
"whirlpool",
Don't build RC4 ciphersuites into libssl by default RC4 based ciphersuites in libssl have been disabled by default. They can be added back by building OpenSSL with the "enable-weak-ssl-ciphers" Configure option at compile time. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 15:40:51 +00:00
"weak-ssl-ciphers",
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
"zlib",
"zlib-dynamic",
);
Support disabling any or all TLS or DTLS versions Some users want to disable SSL 3.0/TLS 1.0/TLS 1.1, and enable just TLS 1.2. In the future they might want to disable TLS 1.2 and enable just TLS 1.3, ... This commit makes it possible to disable any or all of the TLS or DTLS protocols. It also considerably simplifies the SSL/TLS tests, by auto-generating the min/max version tests based on the set of supported protocols (425 explicitly written out tests got replaced by two loops that generate all 425 tests if all protocols are enabled, fewer otherwise). Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-18 18:10:21 +00:00
foreach my $proto ((@tls, @dtls))
{
push(@disablables, $proto);
push(@disablables, "$proto-method");
}
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
Get back "ssl2" as a deprecated disablable option Preserved for now for those who have scripts with the option "no-ssl2". We warn that it's deprecated, and ignore it otherwise. In response to RT#4330 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 09:42:53 +00:00
my @deprecated_disablables = (
"ssl2",
Add buf-freelists to deprecated options The buf-freelists option was removed in master. There may be some things that try to disable it, so don't error out. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-05-23 12:50:32 +00:00
"buf-freelists",
Get back "ssl2" as a deprecated disablable option Preserved for now for those who have scripts with the option "no-ssl2". We warn that it's deprecated, and ignore it otherwise. In response to RT#4330 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 09:42:53 +00:00
);
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
# All of the following is disabled by default (RC5 was enabled before 0.9.8):
Expose %disables to the perl fragments in build.info files. This way, we can use them as conditions instead of relying to more or less obscure aliases in %config or variables directly in Configure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:45:46 +00:00
our %disabled = ( # "what" => "comment"
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
"asan" => "default",
Expose %disables to the perl fragments in build.info files. This way, we can use them as conditions instead of relying to more or less obscure aliases in %config or variables directly in Configure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:45:46 +00:00
"ec_nistp_64_gcc_128" => "default",
Don't build RC4 ciphersuites into libssl by default RC4 based ciphersuites in libssl have been disabled by default. They can be added back by building OpenSSL with the "enable-weak-ssl-ciphers" Configure option at compile time. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 15:40:51 +00:00
"egd" => "default",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
"fuzz" => "default",
Don't build RC4 ciphersuites into libssl by default RC4 based ciphersuites in libssl have been disabled by default. They can be added back by building OpenSSL with the "enable-weak-ssl-ciphers" Configure option at compile time. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 15:40:51 +00:00
"md2" => "default",
"rc5" => "default",
"sctp" => "default",
"ssl-trace" => "default",
Disable SSLv3 by default Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Emilia Kasper <emilia@openssl.org> MR: #2203
2016-03-03 21:45:57 +00:00
"ssl3" => "default",
"ssl3-method" => "default",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
"ubsan" => "default",
Don't build RC4 ciphersuites into libssl by default RC4 based ciphersuites in libssl have been disabled by default. They can be added back by building OpenSSL with the "enable-weak-ssl-ciphers" Configure option at compile time. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 15:40:51 +00:00
"unit-test" => "default",
"weak-ssl-ciphers" => "default",
"zlib" => "default",
"zlib-dynamic" => "default",
"crypto-mdebug" => "default",
Make sure crypto-mdebug-backtrace must be enabled explicitely As it was until now, crypto-mdebug-backtrace was enabled by default and only disabled if crypto-mdebug was disabled. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-05-25 13:42:15 +00:00
"crypto-mdebug-backtrace" => "default",
Don't build RC4 ciphersuites into libssl by default RC4 based ciphersuites in libssl have been disabled by default. They can be added back by building OpenSSL with the "enable-weak-ssl-ciphers" Configure option at compile time. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 15:40:51 +00:00
"heartbeats" => "default",
Expose %disables to the perl fragments in build.info files. This way, we can use them as conditions instead of relying to more or less obscure aliases in %config or variables directly in Configure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:45:46 +00:00
);
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
# Note: => pair form used for aesthetics, not to truly make a hash table
my @disable_cascades = (
# "what" => [ "cascade", ... ]
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
sub { $config{processor} eq "386" }
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
=> [ "sse2" ],
"ssl" => [ "ssl3" ],
"ssl3-method" => [ "ssl3" ],
"zlib" => [ "zlib-dynamic" ],
"des" => [ "mdc2" ],
Remove GOST again The config for the removed GOST engine reappeared by mistake. Now removed again. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-23 21:58:51 +00:00
"ec" => [ "ecdsa", "ecdh" ],
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
sctp requires dgram. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-17 18:17:03 +00:00
"dgram" => [ "dtls", "sctp" ],
Cascade no-dgram from no-sock in Configure not e_os.h e_os.h was defining OPENSSL_NO_DGRAM if OPENSSL_NO_SOCK was defined. This causes link problems on Windows because the generated .def files still contain the DGRAM symbols even though they have not been compiled. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-20 10:24:49 +00:00
"sock" => [ "dgram" ],
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
"dtls" => [ @dtls ],
# SSL 3.0, (D)TLS 1.0 and TLS 1.1 require MD5 and SHA
"md5" => [ "ssl", "tls1", "tls1_1", "dtls1" ],
"sha" => [ "ssl", "tls1", "tls1_1", "dtls1" ],
# Additionally, SSL 3.0 requires either RSA or DSA+DH
sub { $disabled{rsa}
&& ($disabled{dsa} || $disabled{dh}); }
=> [ "ssl" ],
# (D)TLS 1.0 and TLS 1.1 also require either RSA or DSA+DH
# or ECDSA + ECDH. (D)TLS 1.2 has this requirement as well.
# (XXX: We don't support PSK-only builds).
sub { $disabled{rsa}
&& ($disabled{dsa} || $disabled{dh})
&& ($disabled{ecdsa} || $disabled{ecdh}); }
=> [ "tls1", "tls1_1", "tls1_2",
"dtls1", "dtls1_2" ],
"tls" => [ @tls ],
# SRP and HEARTBEATS require TLSEXT
"tlsext" => [ "srp", "heartbeats" ],
Make the use of mdebug backtrace a separate option To force it on anyone using --strict-warnings was the wrong move, as this is an option best left to those who know what they're doing. Use with care! Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-14 11:16:52 +00:00
"crypto-mdebug" => [ "crypto-mdebug-backtrace" ],
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
# Without DSO, we can't load dynamic engines, so don't build them dynamic
"dso" => [ "dynamic-engine" ],
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
# Without position independent code, there can be no shared libraries or DSOs
Don't build dynamic engines unless configured "shared" Experience has shown that dynamic engines with their own copy of libcrypto is problematic, so we disable that possibility. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-11 11:58:15 +00:00
"pic" => [ "shared" ],
"shared" => [ "dynamic-engine" ],
Disable afalg when engine is disabled. Also make it possible to disable afalg separately. we still need to update config again Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-14 11:21:44 +00:00
"engine" => [ "afalgeng" ],
Fix no-stdio and no-autoalginit no-stdio does not work with the apps. Since the tests also need the apps it doesn't support that either. Therefore we disable building of both. no-autoalginit is not compatible with the apps because it requires explicit loading of the algorithms, and the apps don't do that. Therefore we disable building the apps for this option. Similarly the tests depend on the apps so we also disable the tests. Finally the whole point about no-autoalginit is to avoid excessive executable sizes when doing static linking. Therefore we disable "shared" if this option is selected. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-14 12:44:15 +00:00
# no-autoalginit is only useful when building non-shared
"autoalginit" => [ "shared", "apps" ],
"stdio" => [ "apps" ],
"apps" => [ "tests" ],
Fix enable-zlib no-comp. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-22 10:40:13 +00:00
"comp" => [ "zlib" ],
More things that don't work together. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-27 11:28:23 +00:00
sub { !$disabled{"unit-test"} } => [ "heartbeats" ],
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
);
# Avoid protocol support holes. Also disable all versions below N, if version
# N is disabled while N+1 is enabled.
#
my @list = (reverse @tls);
while ((my $first, my $second) = (shift @list, shift @list)) {
last unless @list;
push @disable_cascades, ( sub { !$disabled{$first} && $disabled{$second} }
=> [ @list ] );
unshift @list, $second;
}
my @list = (reverse @dtls);
while ((my $first, my $second) = (shift @list, shift @list)) {
last unless @list;
push @disable_cascades, ( sub { !$disabled{$first} && $disabled{$second} }
=> [ @list ] );
unshift @list, $second;
}
Implement Configure option pattern "experimental-foo" (specifically, "experimental-jpake").
2008-12-02 01:21:39 +00:00
# Explicit "no-..." options will be collected in %disabled along with the defaults.
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
# To remove something from %disabled, use "enable-foo".
Implement Configure option pattern "experimental-foo" (specifically, "experimental-jpake").
2008-12-02 01:21:39 +00:00
# For symmetry, "disable-foo" is a synonym for "no-foo".
Unified build: Keep track of generated header files If someone runs a mixed unixmake / unified environment (the unified build tree would obviously be out of the source tree), the unified build will pick up on the unixmake crypto/buildinf.h because of assumptions made around this sort of declaration (found in crypto/build.info): DEPENDS[cversion.o]=buildinf.h The assumption was that if such a header could be found in the source tree, that was the one to depend on, otherwise it would assume it should be in the build tree. This change makes sure that sort of mix-up won't happen again. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-11 14:22:27 +00:00
my @generated_headers = (
"include/openssl/opensslconf.h",
Let Configure figure out the diverse shared library and DSO extensions Then it can pass around the information where it belongs. The Makefile templates pick it up along with other target data, the DSO module gets to pick up the information through crypto/include/internal/dso_conf.h Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-15 16:20:15 +00:00
"crypto/include/internal/bn_conf.h",
"crypto/include/internal/dso_conf.h"
Unified build: Keep track of generated header files If someone runs a mixed unixmake / unified environment (the unified build tree would obviously be out of the source tree), the unified build will pick up on the unixmake crypto/buildinf.h because of assumptions made around this sort of declaration (found in crypto/build.info): DEPENDS[cversion.o]=buildinf.h The assumption was that if such a header could be found in the source tree, that was the one to depend on, otherwise it would assume it should be in the build tree. This change makes sure that sort of mix-up won't happen again. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-11 14:22:27 +00:00
);
my @generated_by_make_headers = (
"crypto/buildinf.h"
);
It seems that Configure revision 1.404 broke "make depend" by hiding from it which algorithms were disabled. With these new changes, "make depend" will properly take into account algorithms that are skipped.
2005-03-13 19:46:58 +00:00
Add anchors for AES, SHA-256/-512 assembler modules and SSE2 code pathes. I also used this opportunity to clean up some out-of-date targets and re-group targets by OS.
2004-07-18 16:19:34 +00:00
my $no_sse2=0;
Certain missing algorithms make some SSL versions or TLS impossible to build.
2001-11-27 11:48:30 +00:00
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
&usage if ($#ARGV < 0);
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
my $user_cflags="";
my @user_defines=();
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
$config{openssl_api_defines}=[];
$config{openssl_algorithm_defines}=[];
$config{openssl_thread_defines}=[];
$config{openssl_sys_defines}=[];
$config{openssl_other_defines}=[];
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
my $libs="";
my $target="";
Refactor file writing - Adapt util/mkdef.pl to use configdata.pm 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>
2016-01-11 23:17:12 +00:00
$config{options}="";
Configure - get rid of the special debug_ and release_ settings 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>
2016-03-02 18:13:26 +00:00
$config{build_type} = "release";
Allow reconfiguration. This can be useful if some source update requires that you configure again, but you don't want to reenter all those configuration arguments again.
2000-08-17 10:23:45 +00:00
my @argvcopy=@ARGV;
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
if (grep /^reconf(igure)?$/, @argvcopy) {
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
if (-f "./configdata.pm") {
my $file = "./configdata.pm";
unless (my $return = do $file) {
die "couldn't parse $file: $@" if $@;
die "couldn't do $file: $!" unless defined $return;
die "couldn't run $file" unless $return;
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
@argvcopy = defined($configdata::config{perlargv}) ?
@{$configdata::config{perlargv}} : ();
die "Incorrect data to reconfigure, please do a normal configuration\n"
if (grep(/^reconf/,@argvcopy));
$ENV{CROSS_COMPILE} = $configdata::config{cross_compile_prefix}
if defined($configdata::config{cross_compile_prefix});
$ENV{CROSS_COMPILE} = $configdata::config{cc}
if defined($configdata::config{cc});
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
print "Reconfiguring with: ", join(" ",@argvcopy), "\n";
print " CROSS_COMPILE = ",$ENV{CROSS_COMPILE},"\n"
if $ENV{CROSS_COMPILE};
print " CC = ",$ENV{CC},"\n" if $ENV{CC};
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
} elsif (open IN, "<Makefile") {
#
# THIS SECTION IS TEMPORARY, it helps transitioning from Makefile
# centered information gathering the reading configdata.pm
#
while (<IN>) {
Remove last chomps In the previous commit to change all chomp to a more flexible regexp, Configure was forgotten. This completes the change. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-12 11:10:27 +00:00
s|\R$||;
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
if (/^CONFIGURE_ARGS=\s*(.*)\s*/) {
# Older form, we split the string and hope for the best
@argvcopy = split /\s+/, $_;
die "Incorrect data to reconfigure, please do a normal configuration\n"
if (grep(/^reconf/,@argvcopy));
} elsif (/^CROSS_COMPILE=\s*(.*)/) {
$ENV{CROSS_COMPILE}=$1;
} elsif (/^CC=\s*(?:\$\(CROSS_COMPILE\))?(.*?)$/) {
$ENV{CC}=$1;
}
}
#
# END OF TEMPORARY SECTION
#
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
} else {
die "Insufficient data to reconfigure, please do a normal configuration\n";
}
}
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
$config{perlargv} = [ @argvcopy ];
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
my %unsupported_options = ();
Get back "ssl2" as a deprecated disablable option Preserved for now for those who have scripts with the option "no-ssl2". We warn that it's deprecated, and ignore it otherwise. In response to RT#4330 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 09:42:53 +00:00
my %deprecated_options = ();
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
foreach (@argvcopy)
Fix ./Configure reconf './Configure reconf' hasn't been working for a while, because a perl lable needs to be immediately followed by a block. Reviewed-by: Andy Polyakov <appro@openssl.org>
2015-12-02 17:54:15 +00:00
{
Lowercase configuration arguments on VMS Depending on user preferences, Configure might get something like --PREFIX=blah just as well as --prefix=blah, or "SHARED" just as well as "shared". On VMS, let's therefore lowercase at least the portion of the argument before a possible equal sign. For good measure, we lowercase the arguments to be checked in config.com as well. The original argument is sent on to Configure, however. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 15:07:05 +00:00
# VMS is a case insensitive environment, and depending on settings
# out of our control, we may receive options uppercased. Let's
# downcase at least the part before any equal sign.
if ($^O eq "VMS")
{
s/^([^=]*)/lc($1)/e;
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
s /^-no-/no-/; # some people just can't read the instructions
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
# rewrite some options in "enable-..." form
s /^-?-?shared$/enable-shared/;
s /^sctp$/enable-sctp/;
s /^threads$/enable-threads/;
s /^zlib$/enable-zlib/;
s /^zlib-dynamic$/enable-zlib-dynamic/;
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
if (/^(no|disable|enable)-(.+)$/)
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
{
my $word = $2;
Get back "ssl2" as a deprecated disablable option Preserved for now for those who have scripts with the option "no-ssl2". We warn that it's deprecated, and ignore it otherwise. In response to RT#4330 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 09:42:53 +00:00
if (grep { $word =~ /^${_}$/ } @deprecated_disablables)
{
$deprecated_options{$_} = 1;
next;
}
elsif (!grep { $word =~ /^${_}$/ } @disablables)
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
{
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
$unsupported_options{$_} = 1;
next;
Add an explicit list of options that can be disabled, enabled, ... Configure has, so far, had no control at all of which 'no-' options it can be given. This means that, for example, someone could configure with something absurd like 'no-stack' and then watch the build crumble to dust... or file a bug report. This introduces some sanity into the possible choices. The added list comes from looking for the explicit ones used in Configure, and from grepping after OPENSSL_NO_ in all source files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:09:14 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
if (/^no-(.+)$/ || /^disable-(.+)$/)
{
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
foreach my $proto ((@tls, @dtls))
{
if ($1 eq "$proto-method")
{
$disabled{"$proto"} = "option($proto-method)";
last;
}
}
if ($1 eq "dtls")
{
foreach my $proto (@dtls)
{
$disabled{$proto} = "option(dtls)";
}
When using no-dtls create OPENSSL_NO_DTLS Reviewed-by: Viktor Dukhovni <viktor@openssl.org> MR: #2452
2016-03-27 22:31:23 +00:00
$disabled{"dtls"} = "option(dtls)";
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
}
elsif ($1 eq "ssl")
{
# Last one of its kind
$disabled{"ssl3"} = "option(ssl)";
}
elsif ($1 eq "tls")
{
# XXX: Tests will fail if all SSL/TLS
# protocols are disabled.
foreach my $proto (@tls)
{
$disabled{$proto} = "option(tls)";
}
}
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
elsif ($1 eq "static-engine")
{
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
delete $disabled{"dynamic-engine"};
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
}
elsif ($1 eq "dynamic-engine")
{
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
$disabled{"dynamic-engine"} = "option";
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
}
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
else
{
$disabled{$1} = "option";
}
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
# No longer an automatic choice
$auto_threads = 0 if ($1 eq "threads");
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-10 16:10:39 +00:00
elsif (/^enable-(.+)$/)
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
{
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
if ($1 eq "static-engine")
{
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
$disabled{"dynamic-engine"} = "option";
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
}
elsif ($1 eq "dynamic-engine")
{
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
delete $disabled{"dynamic-engine"};
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
}
Restore the zlib / zlib-dynamic logic The proper logic is that both zlib and zlib-dynamic are disabled by default and that enabling zlib-dynamic would enable zlib. Somewhere along the way, the logic got changed, zlib-dynamic was enabled by default and zlib didn't get automatically enabled. This change restores the original logic. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 09:07:29 +00:00
elsif ($1 eq "zlib-dynamic")
{
delete $disabled{"zlib"};
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
my $algo = $1;
delete $disabled{$algo};
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
# No longer an automatic choice
$auto_threads = 0 if ($1 eq "threads");
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
elsif (/^--strict-warnings$/)
{
$strict_warnings = 1;
}
elsif (/^--debug$/)
{
Configure - get rid of the special debug_ and release_ settings 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>
2016-03-02 18:13:26 +00:00
$config{build_type} = "debug";
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
elsif (/^--release$/)
{
Configure - get rid of the special debug_ and release_ settings 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>
2016-03-02 18:13:26 +00:00
$config{build_type} = "release";
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
elsif (/^386$/)
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
{ $config{processor}=386; }
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^fips$/)
{
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{fips}=1;
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
elsif (/^rsaref$/)
{
# No RSAref support any more since it's not needed.
# The check for the option is there so scripts aren't
# broken
}
elsif (/^nofipscanistercheck$/)
{
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{fips} = 1;
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
$nofipscanistercheck = 1;
}
elsif (/^[-+]/)
{
Remove --classic build entirely The Unix build was the last to retain the classic build scheme. The new unified scheme has matured enough, even though some details may need polishing. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-02 16:36:52 +00:00
if (/^--prefix=(.*)$/)
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
{
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
$config{prefix}=$1;
Configure et al: move the installation directory logic to Makefiles The logic to figure out the combinations of --prefix and --openssldir has stayed in Configure so far, with Unix paths as defaults. However, since we're making Configure increasingly platform agnostic, these defaults need to change and adapt to the platform, along with the logic to combine them. The easiest to provide for this is to move the logic and the defaults away from Configure and into the build files. This also means that the definition of the macros ENGINESDIR and OPENSSLDIR move away from include/openssl/opensslconf.h and into the build files. Makefile.in is adapted accordingly. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-01-30 01:57:19 +00:00
die "Directory given with --prefix MUST be absolute\n"
unless file_name_is_absolute($config{prefix});
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--api=(.*)$/)
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
{
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{api}=$1;
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--libdir=(.*)$/)
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>
2015-03-17 15:30:54 +00:00
{
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{libdir}=$1;
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>
2015-03-17 15:30:54 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--openssldir=(.*)$/)
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>
2015-03-17 15:30:54 +00:00
{
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
$config{openssldir}=$1;
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>
2015-03-17 15:30:54 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--with-zlib-lib=(.*)$/)
Add fips option into Configure, disable endian code for no-asm and FIPS. Make shared library default for fips.
2011-01-30 00:01:09 +00:00
{
[Configure] Make --with-zlib-* work with configdata.pm Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-03 16:31:40 +00:00
$withargs{zlib_lib}=$1;
Fix indentation
2011-10-19 09:24:22 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--with-zlib-include=(.*)$/)
Allow DSO flags like -fpic, -fPIC, -KPIC etc. to be specified on the `perl Configure ...' command line. This way one can compile OpenSSL libraries with Position Independent Code (PIC) which is needed for linking it into DSOs.
1999-03-06 14:35:03 +00:00
{
Fix the handling of --with-zlib-include The handling was Unix centric, already in Configure. Change that to just collect the value and let the build file templates figure out what to do with it. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-04-12 14:35:32 +00:00
$withargs{zlib_include}=$1;
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--with-fipslibdir=(.*)$/)
Add fipscanisterbuild configuration option and update Makefile.org: doesn't compile yet
2011-01-26 12:31:30 +00:00
{
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{fipslibdir}="$1/";
Add fipscanisterbuild configuration option and update Makefile.org: doesn't compile yet
2011-01-26 12:31:30 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--with-baseaddr=(.*)$/)
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
{
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{baseaddr}="$1";
Allow DSO flags like -fpic, -fPIC, -KPIC etc. to be specified on the `perl Configure ...' command line. This way one can compile OpenSSL libraries with Position Independent Code (PIC) which is needed for linking it into DSOs.
1999-03-06 14:35:03 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--cross-compile-prefix=(.*)$/)
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-29 21:52:08 +00:00
{
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
$config{cross_compile_prefix}=$1;
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-29 21:52:08 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^--config=(.*)$/)
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
{
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
read_config $1;
Allow reconfiguration. This can be useful if some source update requires that you configure again, but you don't want to reenter all those configuration arguments again.
2000-08-17 10:23:45 +00:00
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
elsif (/^-[lL](.*)$/ or /^-Wl,/)
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
{
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
$libs.=$_." ";
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
}
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
elsif (/^-D(.*)$/)
{
push @user_defines, $1;
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
else # common if (/^[-+]/), just pass down...
{
$_ =~ s/%([0-9a-f]{1,2})/chr(hex($1))/gei;
Put user flags last for priority. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-12 19:40:33 +00:00
$user_cflags.=" ".$_;
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
}
else
{
die "target already defined - $target (offending arg: $_)\n" if ($target ne "");
$target=$_;
}
unless ($_ eq $target || /^no-/ || /^disable-/)
{
# "no-..." follows later after implied disactivations
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# have been derived. (Don't take this too seriously,
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
# we really only write OPTIONS to the Makefile out of
# nostalgia.)
Refactor file writing - Adapt util/mkdef.pl to use configdata.pm 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>
2016-01-11 23:17:12 +00:00
if ($config{options} eq "")
{ $config{options} = $_; }
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
else
Refactor file writing - Adapt util/mkdef.pl to use configdata.pm 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>
2016-01-11 23:17:12 +00:00
{ $config{options} .= " ".$_; }
Don't confuse mk1mf.pl by combining multiple options into one.
1999-07-09 12:00:34 +00:00
}
Make Configure die when unsupported options are given Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:33:47 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
if (defined($config{api}) && !exists $apitable->{$config{api}}) {
die "***** Unsupported api compatibility level: $config{api}\n",
Backwards-compatibility subject to OPENSSL_API_COMPAT Provide backwards-compatiblity for functions, macros and include files if OPENSSL_API_COMPAT is either not defined or defined less than the version number of the release in which the feature was deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-05 04:00:33 +00:00
}
Get back "ssl2" as a deprecated disablable option Preserved for now for those who have scripts with the option "no-ssl2". We warn that it's deprecated, and ignore it otherwise. In response to RT#4330 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 09:42:53 +00:00
if (keys %deprecated_options)
{
warn "***** Deprecated options: ",
join(", ", keys %deprecated_options), "\n";
}
Make Configure die when unsupported options are given Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 15:33:47 +00:00
if (keys %unsupported_options)
{
die "***** Unsupported options: ",
join(", ", keys %unsupported_options), "\n";
}
Don't confuse mk1mf.pl by combining multiple options into one.
1999-07-09 12:00:34 +00:00
}
Certain missing algorithms make some SSL versions or TLS impossible to build.
2001-11-27 11:48:30 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
if ($config{fips})
Fix no-dgram. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-12-16 13:25:07 +00:00
{
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
delete $disabled{"shared"} if ($disabled{"shared"} =~ /^default/);
Support disabling any or all TLS or DTLS versions Some users want to disable SSL 3.0/TLS 1.0/TLS 1.1, and enable just TLS 1.2. In the future they might want to disable TLS 1.2 and enable just TLS 1.3, ... This commit makes it possible to disable any or all of the TLS or DTLS protocols. It also considerably simplifies the SSL/TLS tests, by auto-generating the min/max version tests based on the set of supported protocols (425 explicitly written out tests got replaced by two loops that generate all 425 tests if all protocols are enabled, fewer otherwise). Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-18 18:10:21 +00:00
}
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
else
{
@{$config{dirs}} = grep !/^fips$/, @{$config{dirs}};
}
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
my @tocheckfor = (keys %disabled);
while (@tocheckfor) {
my %new_tocheckfor = ();
my @cascade_copy = (@disable_cascades);
while (@cascade_copy) {
my ($test, $descendents) = (shift @cascade_copy, shift @cascade_copy);
if (ref($test) eq "CODE" ? $test->() : defined($disabled{$test})) {
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
foreach(grep { !defined($disabled{$_}) } @$descendents) {
Fix a few Configure errors Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 09:02:13 +00:00
$new_tocheckfor{$_} = 1; $disabled{$_} = "forced";
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
}
Merge from 1.0.0-stable branch.
2009-04-23 16:32:42 +00:00
}
Refactor config - consolidate handling of disabled stuff 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>
2015-05-18 09:03:47 +00:00
}
@tocheckfor = (keys %new_tocheckfor);
}
Add SRP support.
2011-03-12 17:01:19 +00:00
Some assembler-related clean-ups.
1999-05-28 23:18:51 +00:00
if ($target eq "TABLE") {
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
foreach (sort keys %table) {
print_table_entry($_, "TABLE");
}
exit 0;
Some assembler-related clean-ups.
1999-05-28 23:18:51 +00:00
}
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
if ($target eq "LIST") {
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
foreach (sort keys %table) {
print $_,"\n" unless $table{$_}->{template};
}
exit 0;
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
}
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>
2015-03-06 01:00:21 +00:00
if ($target eq "HASH") {
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
print "%table = (\n";
foreach (sort keys %table) {
print_table_entry($_, "HASH");
}
exit 0;
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>
2015-03-06 01:00:21 +00:00
}
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
# Backward compatibility?
At Corinna Vinschen's request, change CygWin32 to Cygwin
2002-02-14 12:28:24 +00:00
if ($target =~ m/^CygWin32(-.*)$/) {
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
$target = "Cygwin".$1;
At Corinna Vinschen's request, change CygWin32 to Cygwin
2002-02-14 12:28:24 +00:00
}
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
foreach (sort (keys %disabled))
{
Refactor file writing - Adapt util/mkdef.pl to use configdata.pm 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>
2016-01-11 23:17:12 +00:00
$config{options} .= " no-$_";
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
printf " no-%-12s %-10s", $_, "[$disabled{$_}]";
if (/^dso$/)
Clean away $no_dso since with have $disabled{dso} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:12:35 +00:00
{ }
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
elsif (/^threads$/)
Clean away $no_threads since we have $disabled{threads} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:03:23 +00:00
{ }
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
elsif (/^shared$/)
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:52:46 +00:00
{ }
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
elsif (/^pic$/)
{ }
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
elsif (/^zlib$/)
Clean away $zlib since with have $disabled{zlib} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:04:45 +00:00
{ }
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
elsif (/^dynamic-engine$/)
Update from stable branch.
2005-11-06 17:58:26 +00:00
{ }
Add the configure option 'no-makedepend' If no makedepend program or equaly capable compiler is present, 'makedepend' gets disabled automatically. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 00:14:29 +00:00
elsif (/^makedepend$/)
{ }
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
elsif (/^zlib-dynamic$/)
{ }
elsif (/^sse2$/)
{ $no_sse2 = 1; }
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
elsif (/^engine$/)
RT4310: Fix varous no-XXX builds When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing. This prevents md_rand.c from failing to build. Probably better to do it this way than to wrap every instance in an explicit #ifdef. A bunch of new socket code got added to a new file crypto/bio/b_addr.c. Make it all go away if OPENSSL_NO_SOCK is defined. Allow configuration with no-ripemd, no-ts, no-ui We use these for the UEFI build. Also remove the 'Really???' comment from no-err and no-locking. We use those too. We need to drop the crypto/engine directory from the build too, and also set OPENSSL_NO_ENGINE Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-02-17 18:33:51 +00:00
{
@{$config{dirs}} = grep !/^engines$/, @{$config{dirs}};
@{$config{sdirs}} = grep !/^engine$/, @{$config{sdirs}};
push @{$config{openssl_other_defines}}, "OPENSSL_NO_ENGINE";
}
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
else
{
my ($ALGO, $algo);
* Configure, crypto/ec/ec.h, crypto/ec/ecp_nistp224.c, util/mkdef.pl: Have EC_NISTP224_64_GCC_128 treated like any algorithm, and have disabled by default. If we don't do it this way, it screws up libeay.num. * util/libeay.num: make update
2011-03-25 09:29:46 +00:00
($ALGO = $algo = $_) =~ tr/[\-a-z]/[_A-Z]/;
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
Partial revert of 1288f26 and fix for no-async The commit 1288f26 says that it fixes no-async, but instead seems to break it. Therefore revert that change and fix no-async. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-18 16:54:16 +00:00
if (/^asm$/ || /^err$/ || /^hw$/ || /^hw-/ || /^async$/
Add an OPENSSL_NO_AUTOERRINIT option This option disables automatic loading of the crypto/ssl error strings in order to keep statically linked executable file size down Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-09 09:39:07 +00:00
|| /^autoalginit/ || /^autoerrinit/)
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
{
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
push @{$config{openssl_other_defines}}, "OPENSSL_NO_$ALGO";
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
print " OPENSSL_NO_$ALGO";
Strip trailing whitespace from Configure.
2014-05-26 16:19:28 +00:00
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
if (/^err$/) { push @user_defines, "OPENSSL_NO_ERR"; }
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
}
else
{
Configure: addendum to OPENSSL_NO_[RMD160|RIPEMD] harmonization. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-01-24 15:46:54 +00:00
($ALGO,$algo) = ("RMD160","rmd160") if ($algo eq "ripemd");
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
push @{$config{openssl_algorithm_defines}}, "OPENSSL_NO_$ALGO";
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
print " OPENSSL_NO_$ALGO";
Remove remaining Kerberos references Following on from the removal of libcrypto and libssl support for Kerberos this commit removes all remaining references to Kerberos. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-12 11:14:13 +00:00
# fix-up crypto/directory name(s)
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$algo="whrlpool" if $algo eq "whirlpool";
$algo="ripemd" if $algo eq "rmd160";
@{$config{sdirs}} = grep { $_ ne $algo} @{$config{sdirs}};
Configure: addendum to OPENSSL_NO_[RMD160|RIPEMD] harmonization. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-01-24 15:46:54 +00:00
Remove remaining Kerberos references Following on from the removal of libcrypto and libssl support for Kerberos this commit removes all remaining references to Kerberos. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-12 11:14:13 +00:00
print " (skip dir)";
Change ./Configure so that certain algorithms can be disabled by default. This is now the case for RC5. As a side effect, the OPTIONS in the Makefile will usually look a little different now, but they are essentially only for information anyway.
2005-02-22 10:29:51 +00:00
}
}
print "\n";
}
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
print "Configuring for $target\n";
# Support for legacy targets having a name starting with 'debug-'
my ($d, $t) = $target =~ m/^(debug-)?(.*)$/;
if ($d) {
Configure - get rid of the special debug_ and release_ settings 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>
2016-03-02 18:13:26 +00:00
$config{build_type} = "debug";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
# If we do not find debug-foo in the table, the target is set to foo.
if (!$table{$target}) {
$target = $t;
}
}
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
$config{target} = $target;
Apply default after having checked the given config target is valid Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 09:23:15 +00:00
my %target = resolve_config($target);
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
&usage if (!%target || $target{template});
Configure - Rename BASE to DEFAULTS and add a few inheritable BASEs 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>
2016-02-27 10:25:33 +00:00
%target = ( %{$table{DEFAULTS}}, %target );
Apply default after having checked the given config target is valid Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 09:23:15 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$target{exe_extension}="";
Misc small fixes. Better libclean that removes the exact files that have been built, nothing more and nothing less. Corrected typo A couple of editorial changes. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-15 21:13:41 +00:00
$target{exe_extension}=".exe" if ($config{target} eq "DJGPP"
|| $config{target} =~ /^(?:Cygwin|mingw)/);
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$target{exe_extension}=".pm" if ($config{target} =~ /vos/);
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
Let Configure figure out the diverse shared library and DSO extensions Then it can pass around the information where it belongs. The Makefile templates pick it up along with other target data, the DSO module gets to pick up the information through crypto/include/internal/dso_conf.h Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-15 16:20:15 +00:00
($target{shared_extension_simple}=$target{shared_extension})
=~ s|\.\$\(SHLIB_MAJOR\)\.\$\(SHLIB_MINOR\)||;
$target{dso_extension}=$target{shared_extension_simple};
($target{shared_import_extension}=$target{shared_extension_simple}.".a")
if ($config{target} =~ /^(?:Cygwin|mingw)/);
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
$config{cross_compile_prefix} = $ENV{'CROSS_COMPILE'}
if $config{cross_compile_prefix} eq "";
Allow cross compilation prefix to come from CROSS_COMPILE environment variable
2009-10-07 16:41:14 +00:00
Configure - make the use of environment variables for overrides consistent We allow some commands to be overriden, but didn't handle that in a consistent manner. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 11:22:15 +00:00
# Allow overriding the names of some tools. USE WITH CARE
Make the use of perl more consistent - In Configure, register the perl interpreter used to run Configure, so that's the one being used throughout instead of something else that Configure happens to find. This is helpful for using a perl version that's not necessarely first in $PATH: /opt/perl/5.22.1/bin/perl ./Configure - Make apps/tsget a generated file, just like apps/CA.pl, so the perl interpreter registered by Configure becomes the hashbang path instead of a hardcoded /usr/bin/perl Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-31 07:27:15 +00:00
$config{perl} = $ENV{'PERL'} || ($^O ne "VMS" ? $^X : "perl");
Configure - make the use of environment variables for overrides consistent We allow some commands to be overriden, but didn't handle that in a consistent manner. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 11:22:15 +00:00
$target{cc} = $ENV{'CC'} || $target{cc} || "cc";
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 13:35:55 +00:00
$target{ranlib} = $ENV{'RANLIB'} || $target{ranlib} ||
Configure: pull 'which' back. At earlier point 'which' was replaced with IPC::Cmd::can_run call. Unfortunately on RPM-based systems it is a separate package and it's not given that it's installed. Resurrected 'which' provides poor-man fallback for IPC::Cmd::can_run. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-20 19:31:11 +00:00
(which("$config{cross_compile_prefix}ranlib") ?
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 13:35:55 +00:00
"\$(CROSS_COMPILE)ranlib" : "true");
Configure - make the use of environment variables for overrides consistent We allow some commands to be overriden, but didn't handle that in a consistent manner. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 11:22:15 +00:00
$target{ar} = $ENV{'AR'} || $target{ar} || "ar";
$target{nm} = $ENV{'NM'} || $target{nm} || "nm";
Add support for RC / WINDRES env variables RT#2558 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-16 15:08:13 +00:00
$target{rc} =
$ENV{'RC'} || $ENV{'WINDRES'} || $target{rc} || "windres";
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>
2015-03-06 01:00:21 +00:00
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
# For cflags, lflags, plib_lflags, ex_libs and defines, add the debug_
# or release_ attributes.
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>
2015-03-06 01:00:21 +00:00
# Do it in such a way that no spurious space is appended (hence the grep).
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
$config{defines} = [];
$config{cflags} = "";
$config{ex_libs} = "";
$config{shared_ldflag} = "";
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
# Make sure build_scheme is consistent.
$target{build_scheme} = [ $target{build_scheme} ]
if ref($target{build_scheme}) ne "ARRAY";
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
my ($builder, $builder_platform, @builder_opts) =
@{$target{build_scheme}};
Add the C macro NDEBUG when configuring for release Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-04-01 14:03:46 +00:00
push @{$config{defines}}, "NDEBUG" if $config{build_type} eq "release";
Modernise the mingw cflags and ldflags Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-05 14:14:45 +00:00
if ($target =~ /^mingw/ && `$target{cc} --target-help 2>&1` =~ m/-mno-cygwin/m)
Configure: make -mno-cygwin optional on mingw platforms. PR: 2381
2010-11-30 22:18:02 +00:00
{
Modernise the mingw cflags and ldflags Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-05 14:14:45 +00:00
$config{cflags} .= " -mno-cygwin";
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
$config{shared_ldflag} .= " -mno-cygwin";
Configure: make -mno-cygwin optional on mingw platforms. PR: 2381
2010-11-30 22:18:02 +00:00
}
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:10:45 +00:00
if ($target =~ /linux.*-mips/ && !$disabled{asm} && $user_cflags !~ /-m(ips|arch=)/) {
Configure: add MIPS targets.
2012-09-15 11:21:50 +00:00
# minimally required architecture flags for assembly modules
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{cflags}="-mips2 $config{cflags}" if ($target =~ /mips32/);
$config{cflags}="-mips3 $config{cflags}" if ($target =~ /mips64/);
Configure: add MIPS targets.
2012-09-15 11:21:50 +00:00
}
If the user said 'shared' and we haven't included support for shared libraries, warn him or her. Reminder by Andrew Marlow <apm35@student.open.ac.uk>
2003-01-11 11:40:39 +00:00
my $no_shared_warn=0;
./Configure to respect $thread_cflag variable.
2005-01-24 15:58:25 +00:00
my $no_user_cflags=0;
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
my $no_user_defines=0;
If the user said 'shared' and we haven't included support for shared libraries, warn him or her. Reminder by Andrew Marlow <apm35@student.open.ac.uk>
2003-01-11 11:40:39 +00:00
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
# The DSO code currently always implements all functions so that no
# applications will have to worry about that from a compilation point
# of view. However, the "method"s may return zero unless that platform
# has support compiled in for them. Currently each method is enabled
# by a define "DSO_<name>" ... we translate the "dso_scheme" config
# string entry into using the following logic;
Clean away $no_dso since with have $disabled{dso} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:12:35 +00:00
if (!$disabled{dso} && $target{dso_scheme} ne "")
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
{
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
$target{dso_scheme} =~ tr/[a-z]/[A-Z]/;
if ($target{dso_scheme} eq "DLFCN")
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
{
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
unshift @{$config{defines}}, "DSO_DLFCN", "HAVE_DLFCN_H";
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
}
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
elsif ($target{dso_scheme} eq "DLFCN_NO_H")
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
{
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
unshift @{$config{defines}}, "DSO_DLFCN";
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
}
else
{
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
unshift @{$config{defines}}, "DSO_$target{dso_scheme}";
This helps make the DSO stuff more portable; * "no-dso" option available in Configure so that all DSO methods will return NULL, overriding any support the platform might otherwise have built. * dlfcn_no_h config string now available rather than just dlfcn. This is for platforms that have dlfcn.h functions but do not have (or need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
}
}
This commit ties the new DSO code (crypto/dso/) into the build for a variety of platforms. A few are missing, and they will be added in eventually, but as this is new stuff, it was better to not break lots of platforms in one go that we can't easily test. The changes to "Configure" should illustrate how to add support to other systems if you feel like having a go. NB: I'll add something shortly to allow you to add "dlfcn.h" support on those platforms that don't have (or need) a dlfcn.h header file. (The symbol for Configure will probably by "dlfcn_no_h"). Thanks to Richard Levitte, who is responsible for the dso_dl.c support, understanding the trickier aspects of the build process, and giving great feedback on everything else. [Don't use this stuff if you're easily offended by changes to the interface or behaviour - it's still work in progress.] PR:
2000-04-04 22:32:19 +00:00
Configure et al: split up the lflags configuration item into two The lflags configuration had a weird syntax with a % as separator. If it was present, whatever came before ended up as PEX_LIBS in Makefile (usually, this is LDFLAGS), while whatever came after ended up as EX_LIBS. This change splits that item into lflags and ex_libs, making their use more explicit. Also, PEX_LIBS in all the Makefiles are renamed to LDFLAGS. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-01-29 17:07:37 +00:00
$config{ex_libs}="$libs$config{ex_libs}" if ($libs ne "");
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:10:45 +00:00
if ($disabled{asm})
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 11:00:56 +00:00
{
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
if ($config{fips})
{
@{$config{defines}} = grep !/^[BL]_ENDIAN$/, @{$config{defines}};
@{$target{defines}} = grep !/^[BL]_ENDIAN$/, @{$target{defines}};
}
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 11:00:56 +00:00
}
IA-32 assembler modules (primarily DES) PIC-ification. Idea is to keep shared libraries shared.
2002-12-13 17:56:14 +00:00
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
# If threads aren't disabled, check how possible they are
unless ($disabled{threads}) {
if ($auto_threads) {
# Enabled by default, disable it forcibly if unavailable
if ($target{thread_scheme} eq "(unknown)") {
$disabled{threads} = "unavailable";
}
} else {
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# The user chose to enable threads explicitly, let's see
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
# if there's a chance that's possible
if ($target{thread_scheme} eq "(unknown)") {
# If the user asked for "threads" and we don't have internal
# knowledge how to do it, [s]he is expected to provide any
# system-dependent compiler options that are necessary. We
# can't truly check that the given options are correct, but
# we expect the user to know what [s]He is doing.
if ($no_user_cflags && $no_user_defines) {
die "You asked for multi-threading support, but didn't\n"
,"provide any system-specific compiler options\n";
}
}
}
}
# If threads still aren't disabled, add a C macro to ensure the source
# code knows about it. Any other flag is taken care of by the configs.
unless($disabled{threads}) {
foreach (("defines", "openssl_thread_defines")) {
push @{$config{$_}}, "OPENSSL_THREADS";
}
}
Add the possibility to specify the use of zlib compression and decompression. It can be set up to link at link time or to load the zlib library at run-time.
2001-07-12 09:11:14 +00:00
Backwards-compatibility subject to OPENSSL_API_COMPAT Provide backwards-compatiblity for functions, macros and include files if OPENSSL_API_COMPAT is either not defined or defined less than the version number of the release in which the feature was deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-05 04:00:33 +00:00
# With "deprecated" disable all deprecated features.
if (defined($disabled{"deprecated"})) {
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
$config{api} = $maxapi;
Backwards-compatibility subject to OPENSSL_API_COMPAT Provide backwards-compatiblity for functions, macros and include files if OPENSSL_API_COMPAT is either not defined or defined less than the version number of the release in which the feature was deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-05 04:00:33 +00:00
}
Turn on OPENSSL_NO_DEPRECATED by default. Also introduce OPENSSL_USE_DEPRECATED. If OPENSSL_NO_DEPRECATED is defined at config stage then OPENSSL_USE_DEPRECATED has no effect - deprecated functions are not available. If OPENSSL_NO_DEPRECATED is not defined at config stage then applications must define OPENSSL_USE_DEPRECATED in order to access deprecated functions. Also introduce compiler warnings for gcc for applications using deprecated functions Reviewed-by: Rich Salz <rsalz@openssl.org>
2014-12-17 13:17:26 +00:00
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
if ($target{shared_target} eq "")
IA-32 assembler modules (primarily DES) PIC-ification. Idea is to keep shared libraries shared.
2002-12-13 17:56:14 +00:00
{
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
$no_shared_warn = 1
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:52:46 +00:00
if ((!$disabled{shared} || !$disabled{"dynamic-engine"})
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
&& !$config{fips});
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:52:46 +00:00
$disabled{shared} = "no-shared-target";
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
$disabled{pic} = $disabled{shared} = $disabled{"dynamic-engine"} =
"no-shared-target";
IA-32 assembler modules (primarily DES) PIC-ification. Idea is to keep shared libraries shared.
2002-12-13 17:56:14 +00:00
}
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 15:08:53 +00:00
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
if ($disabled{"dynamic-engine"}) {
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
push @{$config{defines}}, "OPENSSL_NO_DYNAMIC_ENGINE";
$config{dynamic_engines} = 0;
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
} else {
push @{$config{defines}}, "OPENSSL_NO_STATIC_ENGINE";
$config{dynamic_engines} = 1;
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
}
Step 6 of move of engines: rename the macro ENGINE_DYNAMIC_SUPPORT to OPENSSL_NO_DYNAMIC_ENGINE and make sure that gets defined unless shared library support has been specifically requested.
2002-10-11 18:06:08 +00:00
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
unless ($disabled{fuzz}) {
Configure: make it work with Perl 5.10. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 09:44:10 +00:00
push @{$config{dirs}}, "fuzz";
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-26 17:19:14 +00:00
$config{cflags} .= "-fsanitize-coverage=edge,indirect-calls ";
}
unless ($disabled{asan}) {
$config{cflags} .= "-fsanitize=address ";
}
unless ($disabled{ubsan}) {
# -DPEDANTIC or -fnosanitize=aligmnent may also be required on some
# platforms.
$config{cflags} .= "-fsanitize=undefined -fno-sanitize-recover=all ";
}
unless ($disabled{fuzz} && $disabled{asan} && $disabled{ubsan}) {
$config{cflags} .= "-fno-omit-frame-pointer -g ";
}
BSD run-time linkers apparently demand RPATH on .so objects. PR: 1381
2007-09-16 12:23:47 +00:00
#
# Platform fix-ups
#
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
# This saves the build files from having to check
if ($disabled{pic})
{
$target{shared_cflag} = $target{shared_ldflag} =
$target{shared_rcflag} = "";
}
Add OPENSSL_PIC back In the earlier change, where static libraries get built with position independent code, OPENSSL_PIC was removed by mistake. This adds it back. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-02-21 19:52:39 +00:00
else
{
push @{$config{defines}}, "OPENSSL_PIC";
}
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
if ($target{sys_id} ne "")
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-19 16:06:34 +00:00
{
Refactor file writing - make configdata.pm the info center for "reconf" 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>
2015-12-27 01:27:30 +00:00
push @{$config{openssl_sys_defines}}, "OPENSSL_SYS_$target{sys_id}";
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-19 16:06:34 +00:00
}
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:10:45 +00:00
unless ($disabled{asm}) {
Configure - Rename BASE to DEFAULTS and add a few inheritable BASEs 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>
2016-02-27 10:25:33 +00:00
$target{cpuid_asm_src}=$table{DEFAULTS}->{cpuid_asm_src} if ($config{processor} eq "386");
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$target{bn_asm_src} =~ s/\w+-gf2m.c// if (defined($disabled{ec2m}));
If they ask for 386, keep it as 386 as possible...
2004-08-02 22:41:19 +00:00
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
# bn-586 is the only one implementing bn_*_part_words
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "OPENSSL_BN_ASM_PART_WORDS" if ($target{bn_asm_src} =~ /bn-586/);
push @{$config{defines}}, "OPENSSL_IA32_SSE2" if (!$no_sse2 && $target{bn_asm_src} =~ /86/);
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 11:00:56 +00:00
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "OPENSSL_BN_ASM_MONT" if ($target{bn_asm_src} =~ /-mont/);
push @{$config{defines}}, "OPENSSL_BN_ASM_MONT5" if ($target{bn_asm_src} =~ /-mont5/);
push @{$config{defines}}, "OPENSSL_BN_ASM_GF2m" if ($target{bn_asm_src} =~ /-gf2m/);
Throw in Montgomery multiplication assembler for x86_64.
2005-10-07 14:18:06 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
if ($config{fips}) {
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
push @{$config{openssl_other_defines}}, "OPENSSL_FIPS";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
Add fipscanisterbuild configuration option and update Makefile.org: doesn't compile yet
2011-01-26 12:31:30 +00:00
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{sha1_asm_src}) {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "SHA1_ASM" if ($target{sha1_asm_src} =~ /sx86/ || $target{sha1_asm_src} =~ /sha1/);
push @{$config{defines}}, "SHA256_ASM" if ($target{sha1_asm_src} =~ /sha256/);
push @{$config{defines}}, "SHA512_ASM" if ($target{sha1_asm_src} =~ /sha512/);
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{md5_asm_src}) {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "MD5_ASM";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
Configure - Rename BASE to DEFAULTS and add a few inheritable BASEs 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>
2016-02-27 10:25:33 +00:00
$target{cast_asm_src}=$table{DEFAULTS}->{cast_asm_src} unless $disabled{pic}; # CAST assembler is not PIC
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{rmd160_asm_src}) {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "RMD160_ASM";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{aes_asm_src}) {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "AES_ASM" if ($target{aes_asm_src} =~ m/\baes-/);;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# aes-ctr.fake is not a real file, only indication that assembler
Rework framework for assembler support for AES counter mode and add AES_ctr32_encrypt to aes-s390x.pl.
2010-07-09 12:21:52 +00:00
# module implements AES_ctr32_encrypt...
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "AES_CTR_ASM" if ($target{aes_asm_src} =~ s/\s*aes-ctr\.fake//);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# aes-xts.fake indicates presence of AES_xts_[en|de]crypt...
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "AES_XTS_ASM" if ($target{aes_asm_src} =~ s/\s*aes-xts\.fake//);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$target{aes_asm_src} =~ s/\s*(vpaes|aesni)-x86\.s//g if ($no_sse2);
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "VPAES_ASM" if ($target{aes_asm_src} =~ m/vpaes/);
push @{$config{defines}}, "BSAES_ASM" if ($target{aes_asm_src} =~ m/bsaes/);
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{wp_asm_src} =~ /mmx/) {
Configure: restore original logic for -DWHIRLPOOL_ASM. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-29 13:23:24 +00:00
if ($config{processor} eq "386") {
Configure - Rename BASE to DEFAULTS and add a few inheritable BASEs 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>
2016-02-27 10:25:33 +00:00
$target{wp_asm_src}=$table{DEFAULTS}->{wp_asm_src};
Configure: restore original logic for -DWHIRLPOOL_ASM. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-29 13:23:24 +00:00
} elsif (!$disabled{"whirlpool"}) {
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
push @{$config{defines}}, "WHIRLPOOL_ASM";
Configure: restore original logic for -DWHIRLPOOL_ASM. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-29 13:23:24 +00:00
}
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{modes_asm_src} =~ /ghash-/) {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "GHASH_ASM";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{ec_asm_src} =~ /ecp_nistz256/) {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "ECP_NISTZ256_ASM";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($target{poly1305_asm_src} ne "") {
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
push @{$config{defines}}, "POLY1305_ASM";
Refactor config - move templates and template docs to Configurations 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>
2015-05-18 00:54:28 +00:00
}
}
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
Fix check of what makedepprog should be A mistake was made and the setting of this config variable got reverted to an older behavior. This restores the latest. Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-01-27 18:03:13 +00:00
my $ecc = $target{cc};
Add the configure option 'no-makedepend' If no makedepend program or equaly capable compiler is present, 'makedepend' gets disabled automatically. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 00:14:29 +00:00
if ($^O ne "VMS" && !$disabled{makedepend}) {
Don't check for gcc or clang on VMS This check is meaningless on VMS and only produce an error because the underlying shell (DCL) doesn't understand sh syntax such as '2>&1'. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 15:08:06 +00:00
# Is the compiler gcc or clang? $ecc is used below to see if
# error-checking can be turned on.
my $ccpcc = "$config{cross_compile_prefix}$target{cc}";
Configure: remove dependency on 'head'. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-11 11:33:59 +00:00
open(PIPE, "$ccpcc --version 2>&1 |");
my $lines = 2;
Don't check for gcc or clang on VMS This check is meaningless on VMS and only produce an error because the underlying shell (DCL) doesn't understand sh syntax such as '2>&1'. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 15:08:06 +00:00
while ( <PIPE> ) {
Check gcc version to see if it supports -MM and friends According to manuals found here: https://gcc.gnu.org/onlinedocs/, GNU C version 3 and on support the dependency generation options. We therefore need to check the gcc version to see if we're going to use it or makedepend for dependency generation. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-08 16:16:16 +00:00
# Find the version number and save the major.
m|(?:.*)\b(\d+)\.\d+\.\d+\b(?:.*)|;
Configure - don't trust $1 to stick around, save its value away Reviewed-by: Stephen Henson <steve@openssl.org>
2016-03-10 18:33:11 +00:00
my $compiler_major = $1;
Check gcc version to see if it supports -MM and friends According to manuals found here: https://gcc.gnu.org/onlinedocs/, GNU C version 3 and on support the dependency generation options. We therefore need to check the gcc version to see if we're going to use it or makedepend for dependency generation. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-08 16:16:16 +00:00
# We know that GNU C version 3 and up as well as all clang
# versions support dependency generation
Configure - don't trust $1 to stick around, save its value away Reviewed-by: Stephen Henson <steve@openssl.org>
2016-03-10 18:33:11 +00:00
$config{makedepprog} = $ccpcc
Configure: remove dependency on 'head'. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-11 11:33:59 +00:00
if (/clang/ || (/gcc/ && $compiler_major > 3));
Don't check for gcc or clang on VMS This check is meaningless on VMS and only produce an error because the underlying shell (DCL) doesn't understand sh syntax such as '2>&1'. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 15:08:06 +00:00
$ecc = "clang" if /clang/;
$ecc = "gcc" if /gcc/;
Configure: remove dependency on 'head'. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-11 11:33:59 +00:00
last if ($config{makedepprog} || !$lines--);
Don't check for gcc or clang on VMS This check is meaningless on VMS and only produce an error because the underlying shell (DCL) doesn't understand sh syntax such as '2>&1'. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 15:08:06 +00:00
}
close(PIPE);
Add the configure option 'no-makedepend' If no makedepend program or equaly capable compiler is present, 'makedepend' gets disabled automatically. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 00:14:29 +00:00
Configure: pull 'which' back. At earlier point 'which' was replaced with IPC::Cmd::can_run call. Unfortunately on RPM-based systems it is a separate package and it's not given that it's installed. Resurrected 'which' provides poor-man fallback for IPC::Cmd::can_run. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-20 19:31:11 +00:00
$config{makedepprog} = which('makedepend') unless $config{makedepprog};
Add the configure option 'no-makedepend' If no makedepend program or equaly capable compiler is present, 'makedepend' gets disabled automatically. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 00:14:29 +00:00
$disabled{makedepend} = "unavailable" unless $config{makedepprog};
Better check for gcc/clang Iteratively improved with Richard and Andy. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-30 00:50:28 +00:00
}
Fix check of what makedepprog should be A mistake was made and the setting of this config variable got reverted to an older behavior. This restores the latest. Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-01-27 18:03:13 +00:00
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
Add the configure option 'no-makedepend' If no makedepend program or equaly capable compiler is present, 'makedepend' gets disabled automatically. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 00:14:29 +00:00
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
# Deal with bn_ops ###################################################
$config{bn_ll} =0;
$config{export_var_as_fn} =0;
my $def_int="unsigned int";
$config{rc4_int} =$def_int;
Remove EIGHT_BIT and SIXTEEN_BIT Also cleaned up bn_prime.pl to current coding style. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-01-23 18:23:25 +00:00
($config{b64l},$config{b64},$config{b32})=(0,0,1);
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
Move more BN internals to bn_lcl.h There was an unused macro in ssl_locl.h that used an internal type, so I removed it. Move bio_st from bio.h to ossl_type.h Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-01-28 15:13:21 +00:00
my $count = 0;
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
foreach (sort split(/\s+/,$target{bn_ops})) {
Move more BN internals to bn_lcl.h There was an unused macro in ssl_locl.h that used an internal type, so I removed it. Move bio_st from bio.h to ossl_type.h Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-01-28 15:13:21 +00:00
$count++ if /SIXTY_FOUR_BIT|SIXTY_FOUR_BIT_LONG|THIRTY_TWO_BIT/;
$config{export_var_as_fn}=1 if $_ eq 'EXPORT_VAR_AS_FN';
$config{bn_ll}=1 if $_ eq 'BN_LLONG';
$config{rc4_int}="unsigned char" if $_ eq 'RC4_CHAR';
($config{b64l},$config{b64},$config{b32})
=(0,1,0) if $_ eq 'SIXTY_FOUR_BIT';
($config{b64l},$config{b64},$config{b32})
=(1,0,0) if $_ eq 'SIXTY_FOUR_BIT_LONG';
($config{b64l},$config{b64},$config{b32})
=(0,0,1) if $_ eq 'THIRTY_TWO_BIT';
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
}
Move more BN internals to bn_lcl.h There was an unused macro in ssl_locl.h that used an internal type, so I removed it. Move bio_st from bio.h to ossl_type.h Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-01-28 15:13:21 +00:00
die "Exactly one of SIXTY_FOUR_BIT|SIXTY_FOUR_BIT_LONG|THIRTY_TWO_BIT can be set in bn_ops\n"
if $count > 1;
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
# Hack cflags for better warnings (dev option) #######################
Reformat the CFLAG string so it can be made part of a C string. Incidently, this works pretty well on the command line as well. PR: 52
2002-05-30 18:06:35 +00:00
# "Stringify" the C flags string. This permits it to be made part of a string
# and works as well on command lines.
Fix a few Configure errors Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 09:02:13 +00:00
$config{cflags} =~ s/([\\\"])/\\$1/g;
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 15:08:53 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
if (defined($config{api})) {
$config{openssl_api_defines} = [ "OPENSSL_MIN_API=".$apitable->{$config{api}} ];
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
my $apiflag = sprintf("OPENSSL_API_COMPAT=%s", $apitable->{$config{api}});
push @{$config{defines}}, $apiflag;
Backwards-compatibility subject to OPENSSL_API_COMPAT Provide backwards-compatiblity for functions, macros and include files if OPENSSL_API_COMPAT is either not defined or defined less than the version number of the release in which the feature was deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-05 04:00:33 +00:00
}
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
if ($strict_warnings)
{
my $wopt;
Better check for gcc/clang Iteratively improved with Richard and Andy. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-30 00:50:28 +00:00
die "ERROR --strict-warnings requires gcc or clang"
unless $ecc eq 'gcc' || $ecc eq 'clang';
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
foreach $wopt (split /\s+/, $gcc_devteam_warn)
{
Fix check of -DOPENSSL_USE_APPLINK in $config{cflags} The previous fix wasn't right. Also, change all (^|\s) and (\s|$) constructs to (?:^|\s) and (?:\s|$). Perl seems to like that better. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 22:27:13 +00:00
$config{cflags} .= " $wopt" unless ($config{cflags} =~ /(?:^|\s)$wopt(?:\s|$)/)
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
}
Fix build on MacOS. Reviewed-by: Andy Polyakov
2015-04-19 13:10:54 +00:00
if ($ecc eq "clang")
{
foreach $wopt (split /\s+/, $clang_devteam_warn)
{
Fix check of -DOPENSSL_USE_APPLINK in $config{cflags} The previous fix wasn't right. Also, change all (^|\s) and (\s|$) constructs to (?:^|\s) and (?:\s|$). Perl seems to like that better. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 22:27:13 +00:00
$config{cflags} .= " $wopt" unless ($config{cflags} =~ /(?:^|\s)$wopt(?:\s|$)/)
Fix build on MacOS. Reviewed-by: Andy Polyakov
2015-04-19 13:10:54 +00:00
}
}
Make the use of mdebug backtrace a separate option To force it on anyone using --strict-warnings was the wrong move, as this is an option best left to those who know what they're doing. Use with care! Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-14 11:16:52 +00:00
}
unless ($disabled{"crypto-mdebug-backtrace"})
{
foreach my $wopt (split /\s+/, $memleak_devteam_backtrace)
Move the backtrace memleak options to a separate variable The contents of this variable ($memleak_devteam_backtrace) is added to $cflags unless we build for a platform we know doesn't support gcc's -rdynamic och backtrace() and friends. Reviewed-by: Andy Polyakov <appro@openssl.org>
2015-12-02 17:44:26 +00:00
{
Fix check of -DOPENSSL_USE_APPLINK in $config{cflags} The previous fix wasn't right. Also, change all (^|\s) and (\s|$) constructs to (?:^|\s) and (?:\s|$). Perl seems to like that better. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-16 22:27:13 +00:00
$config{cflags} .= " $wopt" unless ($config{cflags} =~ /(?:^|\s)$wopt(?:\s|$)/)
Make the use of mdebug backtrace a separate option To force it on anyone using --strict-warnings was the wrong move, as this is an option best left to those who know what they're doing. Use with care! Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-14 11:16:52 +00:00
}
if ($target =~ /^BSD-/)
{
$config{ex_libs} .= " -lexecinfo";
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
}
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-09 16:31:32 +00:00
}
Rethink the method to place user cflags last The previous method had some unfortunate consequences with --strict-warnings. To counteract, revert part of the previous change and move down the block of code that adds the user cflags and defines. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-13 12:02:35 +00:00
if ($user_cflags ne "") { $config{cflags}="$config{cflags}$user_cflags"; }
else { $no_user_cflags=1; }
if (@user_defines) { $config{defines}=[ @{$config{defines}}, @user_defines ]; }
else { $no_user_defines=1; }
# ALL MODIFICATIONS TO %config and %target MUST BE DONE FROM HERE ON
Disable afalg when engine is disabled. Also make it possible to disable afalg separately. we still need to update config again Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-14 11:21:44 +00:00
unless ($disabled{afalgeng}) {
$config{afalgeng}="";
Don't check the conditions to build e_afalg if configured "no-engine" Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 08:04:01 +00:00
if ($target =~ m/^linux/) {
my $minver = 4*10000 + 1*100 + 0;
if ($config{cross_compile_prefix} eq "") {
my $verstr = `uname -r`;
my ($ma, $mi1, $mi2) = split("\\.", $verstr);
($mi2) = $mi2 =~ /(\d+)/;
my $ver = $ma*10000 + $mi1*100 + $mi2;
if ($ver < $minver) {
Disable afalg when engine is disabled. Also make it possible to disable afalg separately. we still need to update config again Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-14 11:21:44 +00:00
$disabled{afalgeng} = "too-old-kernel";
Don't check the conditions to build e_afalg if configured "no-engine" Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 08:04:01 +00:00
} else {
push @{$config{engdirs}}, "afalg";
}
Disable AFALG when cross-compiling We don't currently support cross-compiling of the afalg engine. However we were failing to explicitly mark it as disabled during Configure leading to a failed build. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-16 10:08:53 +00:00
} else {
$disabled{afalgeng} = "cross-compiling";
Rework based on feedback: 1. Cleaned up eventfd handling 2. Reworked socket setup code to allow other algorithms to be added in future 3. Fixed compile errors for static build 4. Added error to error stack in all cases of ALG_PERR/ALG_ERR 5. Called afalg_aes_128_cbc() from bind() to avoid race conditions 6. Used MAX_INFLIGHT define in io_getevents system call 7. Coding style fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-23 08:01:01 +00:00
}
Don't check the conditions to build e_afalg if configured "no-engine" Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 08:04:01 +00:00
} else {
Disable afalg when engine is disabled. Also make it possible to disable afalg separately. we still need to update config again Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-14 11:21:44 +00:00
$disabled{afalgeng} = "not-linux";
ALG: Add AFALG engine Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-17 13:38:36 +00:00
}
}
Misc afalg build fixes Misc afalg build fixes as suggested by Richard Levitte for the latest Configure changes. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-29 13:36:47 +00:00
Disable afalg when engine is disabled. Also make it possible to disable afalg separately. we still need to update config again Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-14 11:21:44 +00:00
push @{$config{openssl_other_defines}}, "OPENSSL_NO_AFALGENG" if ($disabled{afalgeng});
ALG: Add AFALG engine Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-17 13:38:36 +00:00
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# If we use the unified build, collect information from build.info files
my %unified_info = ();
Added build.info debugging capability to Configure This is only enabled when the environment variable CONFIGURE_DEBUG_BUILDINFO is defined. This will cause every line in every build.info file to be displayed, along with the content of the skip stack before and after parsing. This can be a very powerful tool to see that all conditions are working as expected. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 23:04:04 +00:00
my $buildinfo_debug = defined($ENV{CONFIGURE_DEBUG_BUILDINFO});
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
if ($builder eq "unified") {
# Store the name of the template file we will build the build file from
# in %config. This may be useful for the build file itself.
Add the possibility for local build file templates Use the environment variable OPENSSL_LOCAL_CONFIG_DIR to find build file templates as well. Reviewed-by: Stephen Henson <steve@openssl.org>
2016-05-02 15:05:48 +00:00
my $build_file_template;
for my $filename (( $builder_platform."-".$target{build_file}.".tmpl",
$target{build_file}.".tmpl" )) {
if (defined $ENV{$local_config_envname}) {
if ($^O eq 'VMS') {
# VMS environment variables are logical names,
# which can be used as is
$build_file_template = $local_config_envname . ':' . $filename;
} else {
$build_file_template = catfile($ENV{$local_config_envname},
$filename);
}
}
last if -f $build_file_template;
$build_file_template = catfile($srcdir, "Configurations", $filename);
last if -f $build_file_template;
}
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
$config{build_file_template} = $build_file_template;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
use lib catdir(dirname(__FILE__),"util");
use with_fallback qw(Text::Template);
sub cleandir {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $base = shift;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $dir = shift;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $relativeto = shift || ".";
$dir = catdir($base,$dir) unless isabsolute($dir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
Use rel2abs() on VMS, rather than realpath() It seems realpath() is quite buggy on VMS, or will at least give quite surprising results. On the other hand, realpath() is the better on Unix to clean out clutter like foo/../bar on Unix. So we make out own function to get the absolute directory for a given input, and use rel2abs() or realpath() depending on the platform Configure runs on. Issue reported by Steven M. Schweda <sms@antinode.info> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-09 09:15:13 +00:00
# Make sure the directories we're building in exists
mkpath($dir);
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $res = abs2rel(absolutedir($dir), rel2abs($relativeto));
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
#print STDERR "DEBUG[cleandir]: $dir , $base => $res\n";
return $res;
}
sub cleanfile {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $base = shift;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $file = shift;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $relativeto = shift || ".";
$file = catfile($base,$file) unless isabsolute($file);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $d = dirname($file);
my $f = basename($file);
Use rel2abs() on VMS, rather than realpath() It seems realpath() is quite buggy on VMS, or will at least give quite surprising results. On the other hand, realpath() is the better on Unix to clean out clutter like foo/../bar on Unix. So we make out own function to get the absolute directory for a given input, and use rel2abs() or realpath() depending on the platform Configure runs on. Issue reported by Steven M. Schweda <sms@antinode.info> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-09 09:15:13 +00:00
# Make sure the directories we're building in exists
mkpath($d);
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $res = abs2rel(catfile(absolutedir($d), $f), rel2abs($relativeto));
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
#print STDERR "DEBUG[cleanfile]: $d , $f => $res\n";
return $res;
}
my @build_infos = ( [ ".", "build.info" ] );
foreach (@{$config{dirs}}) {
push @build_infos, [ $_, "build.info" ]
if (-f catfile($srcdir, $_, "build.info"));
}
foreach (@{$config{sdirs}}) {
push @build_infos, [ catdir("crypto", $_), "build.info" ]
if (-f catfile($srcdir, "crypto", $_, "build.info"));
}
foreach (@{$config{engdirs}}) {
push @build_infos, [ catdir("engines", $_), "build.info" ]
if (-f catfile($srcdir, "engines", $_, "build.info"));
}
Unified - have configdata.pm depend on a few more things Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-28 00:13:17 +00:00
$config{build_infos} = [ ];
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
foreach (@build_infos) {
my $sourced = catdir($srcdir, $_->[0]);
my $buildd = catdir($blddir, $_->[0]);
Use File::Path::mkpath rather than File::Path::make_path File::Path::make_path didn't show up before File::Path 2.06 / perl v5.10.1. Because we're trying to stay compatible with perl v5.10.0 and up, it's better to use the legacy interface. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-08 15:27:15 +00:00
mkpath($buildd);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $f = $_->[1];
# The basic things we're trying to build
my @programs = ();
my @libraries = ();
my @engines = ();
my @scripts = ();
my @extra = ();
Unified - Add the build.info command OVERRIDE, to avoid build file clashes Should it be needed because the recipes within a RAW section might clash with those generated by Configure, it's possible to tell it not to generate them with the use of OVERRIDES, for example: SOURCE[libfoo]=foo.c bar.c OVERRIDES=bar.o BEGINRAW[Makefile(unix)] bar.o: bar.c $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< ENDRAW[Makefile(unix)] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:50:37 +00:00
my @overrides = ();
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my @intermediates = ();
my @rawlines = ();
my %ordinals = ();
my %sources = ();
Make it possible to specify source files that will only be used for shared libs There are rare cases when an object file will only be used when building a shared library. To enable this, we introduce SHARED_SOURCE: SHARED_SOURCE[libfoo]=dllmain.c Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-29 14:45:03 +00:00
my %shared_sources = ();
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my %includes = ();
my %depends = ();
my %renames = ();
my %sharednames = ();
Unified - Add the build.info command GENERATE, to generate source files In some cases, one might want to generate some source files from others, that's done as follows: GENERATE[foo.s]=asm/something.pl $(CFLAGS) GENERATE[bar.s]=asm/bar.S The value of each GENERATE line is a command line or part of it. Configure places no rules on the command line, except the the first item muct be the generator file. It is, however, entirely up to the build file template to define exactly how those command lines should be handled, how the output is captured and so on. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:37:00 +00:00
my %generate = ();
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
Unified - have configdata.pm depend on a few more things Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-28 00:13:17 +00:00
push @{$config{build_infos}}, catfile(abs2rel($sourced, $blddir), $f);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $template = Text::Template->new(TYPE => 'FILE',
SOURCE => catfile($sourced, $f));
die "Something went wrong with $sourced/$f: $!\n" unless $template;
my @text =
split /^/m,
$template->fill_in(HASH => { config => \%config,
target => \%target,
Expose %disables to the perl fragments in build.info files. This way, we can use them as conditions instead of relying to more or less obscure aliases in %config or variables directly in Configure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:45:46 +00:00
disabled => \%disabled,
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
builddir => abs2rel($buildd, $blddir),
sourcedir => abs2rel($sourced, $blddir),
buildtop => abs2rel($blddir, $blddir),
sourcetop => abs2rel($srcdir, $blddir) },
DELIMITERS => [ "{-", "-}" ]);
# The top item of this stack has the following values
# -2 positive already run and we found ELSE (following ELSIF should fail)
# -1 positive already run (skip until ENDIF)
# 0 negatives so far (if we're at a condition, check it)
# 1 last was positive (don't skip lines until next ELSE, ELSIF or ENDIF)
# 2 positive ELSE (following ELSIF should fail)
my @skip = ();
collect_information(
collect_from_array([ @text ],
qr/\\$/ => sub { my $l1 = shift; my $l2 = shift;
$l1 =~ s/\\$//; $l1.$l2 }),
# Info we're looking for
qr/^\s*IF\[((?:\\.|[^\\\]])*)\]\s*$/
In build.info, an IF within a clause that's skipped over shouldn't apply If we find an IF within a clause that's skipped over, set it to be skipped as well. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 13:33:37 +00:00
=> sub {
Correct slight logic error in processing IF in build.info This corrects a fault where the inner IF in this example was still being acted upon: IF[0] ...whatever... IF[1] ...whatever more... ENDIF ENDIF With this change, the inner IF is skipped over. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 22:58:44 +00:00
if (! @skip || $skip[$#skip] > 0) {
In build.info, an IF within a clause that's skipped over shouldn't apply If we find an IF within a clause that's skipped over, set it to be skipped as well. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 13:33:37 +00:00
push @skip, !! $1;
} else {
push @skip, -1;
}
},
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
qr/^\s*ELSIF\[((?:\\.|[^\\\]])*)\]\s*$/
=> sub { die "ELSIF out of scope" if ! @skip;
die "ELSIF following ELSE" if abs($skip[$#skip]) == 2;
$skip[$#skip] = -1 if $skip[$#skip] != 0;
$skip[$#skip] = !! $1
if $skip[$#skip] == 0; },
qr/^\s*ELSE\s*$/
=> sub { die "ELSE out of scope" if ! @skip;
$skip[$#skip] = -2 if $skip[$#skip] != 0;
$skip[$#skip] = 2 if $skip[$#skip] == 0; },
qr/^\s*ENDIF\s*$/
=> sub { die "ENDIF out of scope" if ! @skip;
pop @skip; },
qr/^\s*PROGRAMS\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @programs, tokenize($1)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*LIBS\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @libraries, tokenize($1)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*ENGINES\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @engines, tokenize($1)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*SCRIPTS\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @scripts, tokenize($1)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*EXTRA\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @extra, tokenize($1)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
Unified - Add the build.info command OVERRIDE, to avoid build file clashes Should it be needed because the recipes within a RAW section might clash with those generated by Configure, it's possible to tell it not to generate them with the use of OVERRIDES, for example: SOURCE[libfoo]=foo.c bar.c OVERRIDES=bar.o BEGINRAW[Makefile(unix)] bar.o: bar.c $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< ENDRAW[Makefile(unix)] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:50:37 +00:00
qr/^\s*OVERRIDES\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @overrides, tokenize($1)
Unified - Add the build.info command OVERRIDE, to avoid build file clashes Should it be needed because the recipes within a RAW section might clash with those generated by Configure, it's possible to tell it not to generate them with the use of OVERRIDES, for example: SOURCE[libfoo]=foo.c bar.c OVERRIDES=bar.o BEGINRAW[Makefile(unix)] bar.o: bar.c $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< ENDRAW[Makefile(unix)] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:50:37 +00:00
if !@skip || $skip[$#skip] > 0 },
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
qr/^\s*ORDINALS\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/,
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$ordinals{$1}}, tokenize($2)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*SOURCE\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$sources{$1}}, tokenize($2)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
Make it possible to specify source files that will only be used for shared libs There are rare cases when an object file will only be used when building a shared library. To enable this, we introduce SHARED_SOURCE: SHARED_SOURCE[libfoo]=dllmain.c Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-29 14:45:03 +00:00
qr/^\s*SHARED_SOURCE\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$shared_sources{$1}}, tokenize($2)
Make it possible to specify source files that will only be used for shared libs There are rare cases when an object file will only be used when building a shared library. To enable this, we introduce SHARED_SOURCE: SHARED_SOURCE[libfoo]=dllmain.c Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-29 14:45:03 +00:00
if !@skip || $skip[$#skip] > 0 },
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
qr/^\s*INCLUDE\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$includes{$1}}, tokenize($2)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*DEPEND\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$depends{$1}}, tokenize($2)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
Unified - Add the build.info command GENERATE, to generate source files In some cases, one might want to generate some source files from others, that's done as follows: GENERATE[foo.s]=asm/something.pl $(CFLAGS) GENERATE[bar.s]=asm/bar.S The value of each GENERATE line is a command line or part of it. Configure places no rules on the command line, except the the first item muct be the generator file. It is, however, entirely up to the build file template to define exactly how those command lines should be handled, how the output is captured and so on. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:37:00 +00:00
qr/^\s*GENERATE\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
=> sub { push @{$generate{$1}}, $2
if !@skip || $skip[$#skip] > 0 },
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
qr/^\s*RENAME\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$renames{$1}}, tokenize($2)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*SHARED_NAME\[((?:\\.|[^\\\]])+)\]\s*=\s*(.*)\s*$/
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
=> sub { push @{$sharednames{$1}}, tokenize($2)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if !@skip || $skip[$#skip] > 0 },
qr/^\s*BEGINRAW\[((?:\\.|[^\\\]])+)\]\s*$/
=> sub {
my $lineiterator = shift;
my $target_kind = $1;
while (defined $lineiterator->()) {
Remove last chomps In the previous commit to change all chomp to a more flexible regexp, Configure was forgotten. This completes the change. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-12 11:10:27 +00:00
s|\R$||;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if (/^\s*ENDRAW\[((?:\\.|[^\\\]])+)\]\s*$/) {
die "ENDRAW doesn't match BEGINRAW"
if $1 ne $target_kind;
last;
}
next if @skip && $skip[$#skip] <= 0;
push @rawlines, $_
if ($target_kind eq $target{build_file}
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
|| $target_kind eq $target{build_file}."(".$builder_platform.")");
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
}
},
qr/^(?:#.*|\s*)$/ => sub { },
Added build.info debugging capability to Configure This is only enabled when the environment variable CONFIGURE_DEBUG_BUILDINFO is defined. This will cause every line in every build.info file to be displayed, along with the content of the skip stack before and after parsing. This can be a very powerful tool to see that all conditions are working as expected. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 23:04:04 +00:00
"OTHERWISE" => sub { die "Something wrong with this line:\n$_\nat $sourced/$f" },
"BEFORE" => sub {
if ($buildinfo_debug) {
print STDERR "DEBUG: Parsing ",join(" ", @_),"\n";
print STDERR "DEBUG: ... before parsing, skip stack is ",join(" ", map { int($_) } @skip),"\n";
}
},
"AFTER" => sub {
if ($buildinfo_debug) {
print STDERR "DEBUG: .... after parsing, skip stack is ",join(" ", map { int($_) } @skip),"\n";
}
},
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
);
die "runaway IF?" if (@skip);
foreach (keys %renames) {
die "$_ renamed to more than one thing: "
,join(" ", @{$renames{$_}}),"\n"
if scalar @{$renames{$_}} > 1;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $dest = cleanfile($buildd, $_, $blddir);
my $to = cleanfile($buildd, $renames{$_}->[0], $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
die "$dest renamed to more than one thing: "
,$unified_info{rename}->{$dest}, $to
unless !defined($unified_info{rename}->{$dest})
or $unified_info{rename}->{$dest} eq $to;
$unified_info{rename}->{$dest} = $to;
}
foreach (@programs) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $program = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$program}) {
$program = $unified_info{rename}->{$program};
}
$unified_info{programs}->{$program} = 1;
}
foreach (@libraries) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $library = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$library}) {
$library = $unified_info{rename}->{$library};
}
$unified_info{libraries}->{$library} = 1;
}
Build dynamic engines even if configured "no-shared" Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-19 21:08:37 +00:00
die <<"EOF" if scalar @engines and !$config{dynamic_engines};
Use $disabled{"dynamic-engine"} internally We were kinda sorta using a mix of $disabled{"static-engine" and $disabled{"dynamic-engine"} in Configure. Let's avoid confusion, choose one of them and stick to it. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:06:05 +00:00
ENGINES can only be used if configured with 'dynamic-engine'.
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
This is usually a fault in a build.info file.
EOF
foreach (@engines) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $library = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$library}) {
$library = $unified_info{rename}->{$library};
}
$unified_info{engines}->{$library} = 1;
}
foreach (@scripts) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $script = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$script}) {
$script = $unified_info{rename}->{$script};
}
$unified_info{scripts}->{$script} = 1;
}
foreach (@extra) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $extra = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$unified_info{extra}->{$extra} = 1;
}
Unified - Add the build.info command OVERRIDE, to avoid build file clashes Should it be needed because the recipes within a RAW section might clash with those generated by Configure, it's possible to tell it not to generate them with the use of OVERRIDES, for example: SOURCE[libfoo]=foo.c bar.c OVERRIDES=bar.o BEGINRAW[Makefile(unix)] bar.o: bar.c $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< ENDRAW[Makefile(unix)] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:50:37 +00:00
foreach (@overrides) {
my $override = cleanfile($buildd, $_, $blddir);
$unified_info{overrides}->{$override} = 1;
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
push @{$unified_info{rawlines}}, @rawlines;
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:52:46 +00:00
unless ($disabled{shared}) {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# Check sharednames.
foreach (keys %sharednames) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $dest = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$dest}) {
$dest = $unified_info{rename}->{$dest};
}
die "shared_name for $dest with multiple values: "
,join(" ", @{$sharednames{$_}}),"\n"
if scalar @{$sharednames{$_}} > 1;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $to = cleanfile($buildd, $sharednames{$_}->[0], $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
die "shared_name found for a library $dest that isn't defined\n"
unless $unified_info{libraries}->{$dest};
die "shared_name for $dest with multiple values: "
,$unified_info{sharednames}->{$dest}, ", ", $to
unless !defined($unified_info{sharednames}->{$dest})
or $unified_info{sharednames}->{$dest} eq $to;
$unified_info{sharednames}->{$dest} = $to;
}
# Additionally, we set up sharednames for libraries that don't
# have any, as themselves.
foreach (keys %{$unified_info{libraries}}) {
if (!defined $unified_info{sharednames}->{$_}) {
$unified_info{sharednames}->{$_} = $_
}
}
}
foreach (keys %ordinals) {
my $dest = $_;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $ddest = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$ddest}) {
$ddest = $unified_info{rename}->{$ddest};
}
foreach (@{$ordinals{$dest}}) {
my %known_ordinals =
(
crypto =>
Change names of ordinals and libs, libeay => libcrypto and ssleay => libssl Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 11:42:01 +00:00
cleanfile($sourced, catfile("util", "libcrypto.num"), $blddir),
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
ssl =>
Change names of ordinals and libs, libeay => libcrypto and ssleay => libssl Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 11:42:01 +00:00
cleanfile($sourced, catfile("util", "libssl.num"), $blddir)
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
);
my $o = $known_ordinals{$_};
die "Ordinals for $ddest defined more than once\n"
if $unified_info{ordinals}->{$ddest};
$unified_info{ordinals}->{$ddest} = [ $_, $o ];
}
}
foreach (keys %sources) {
my $dest = $_;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $ddest = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if ($unified_info{rename}->{$ddest}) {
$ddest = $unified_info{rename}->{$ddest};
}
foreach (@{$sources{$dest}}) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $s = cleanfile($sourced, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# If it isn't in the source tree, we assume it's generated
# in the build tree
if (! -f $s) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
$s = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
}
# We recognise C and asm files
if ($s =~ /\.[csS]\b$/) {
(my $o = $_) =~ s/\.[csS]\b$/.o/;
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
$o = cleanfile($buildd, $o, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$unified_info{sources}->{$ddest}->{$o} = 1;
$unified_info{sources}->{$o}->{$s} = 1;
} else {
$unified_info{sources}->{$ddest}->{$s} = 1;
}
}
}
Make it possible to specify source files that will only be used for shared libs There are rare cases when an object file will only be used when building a shared library. To enable this, we introduce SHARED_SOURCE: SHARED_SOURCE[libfoo]=dllmain.c Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-29 14:45:03 +00:00
foreach (keys %shared_sources) {
my $dest = $_;
my $ddest = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$ddest}) {
$ddest = $unified_info{rename}->{$ddest};
}
foreach (@{$shared_sources{$dest}}) {
my $s = cleanfile($sourced, $_, $blddir);
# If it isn't in the source tree, we assume it's generated
# in the build tree
if (! -f $s) {
$s = cleanfile($buildd, $_, $blddir);
}
# We recognise C and asm files
if ($s =~ /\.[csS]\b$/) {
(my $o = $_) =~ s/\.[csS]\b$/.o/;
$o = cleanfile($buildd, $o, $blddir);
$unified_info{shared_sources}->{$ddest}->{$o} = 1;
$unified_info{sources}->{$o}->{$s} = 1;
} else {
die "unrecognised source file type for shared library: $s\n";
}
}
}
Unified - Add the build.info command GENERATE, to generate source files In some cases, one might want to generate some source files from others, that's done as follows: GENERATE[foo.s]=asm/something.pl $(CFLAGS) GENERATE[bar.s]=asm/bar.S The value of each GENERATE line is a command line or part of it. Configure places no rules on the command line, except the the first item muct be the generator file. It is, however, entirely up to the build file template to define exactly how those command lines should be handled, how the output is captured and so on. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:37:00 +00:00
foreach (keys %generate) {
my $dest = $_;
my $ddest = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$ddest}) {
$ddest = $unified_info{rename}->{$ddest};
}
die "more than one generator for $dest: "
,join(" ", @{$generate{$_}}),"\n"
if scalar @{$generate{$_}} > 1;
my @generator = split /\s+/, $generate{$dest}->[0];
$generator[0] = cleanfile($sourced, $generator[0], $blddir),
$unified_info{generate}->{$ddest} = [ @generator ];
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
foreach (keys %depends) {
my $dest = $_;
Build system: add include directories and dependencies for generators In the case of generating a file like this: GENERATE[foo.S]=mkfoo.pl arg1 arg2 the 'mkfoo.pl' generator itself might need to include other files, such as perl modules within our source tree. We can reuse already existing syntax for it, like this: INCLUDE[mkfoo.pl]=module/path or: DEPEND[mkfoo.pl]=modules/mymodule.pm This change implements the support for such constructs, and for the DEPEND statement, for any value that indicates a perl module (.pm file), it will automatically infer an INCLUDE statement for its directory, just like it does for C header files, so you won't have do write this: DEPEND[mkfoo.pl]=modules/mymodule.pm INCLUDE[mkfoo.pl]=modules Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-04-21 12:30:08 +00:00
my $ddest = cleanfile($sourced, $_, $blddir);
# If the destination doesn't exist in source, it can only be
# a generated file in the build tree.
if (! -f $ddest) {
$ddest = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$ddest}) {
$ddest = $unified_info{rename}->{$ddest};
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
}
foreach (@{$depends{$dest}}) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $d = cleanfile($sourced, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
Unified build: Keep track of generated header files If someone runs a mixed unixmake / unified environment (the unified build tree would obviously be out of the source tree), the unified build will pick up on the unixmake crypto/buildinf.h because of assumptions made around this sort of declaration (found in crypto/build.info): DEPENDS[cversion.o]=buildinf.h The assumption was that if such a header could be found in the source tree, that was the one to depend on, otherwise it would assume it should be in the build tree. This change makes sure that sort of mix-up won't happen again. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-11 14:22:27 +00:00
# If we know it's generated, or assume it is because we can't
# find it in the source tree, we set file we depend on to be
# in the build tree rather than the source tree, and assume
# and that there are lines to build it in a BEGINRAW..ENDRAW
# section or in the Makefile template.
if (! -f $d
Correct the check of files to depend on against known generated ones The check was erroneously inversed Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-19 00:29:01 +00:00
|| (grep { $d eq $_ }
map { cleanfile($srcdir, $_, $blddir) }
(@generated_headers, @generated_by_make_headers))) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
$d = cleanfile($buildd, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
}
# Take note if the file to depend on is being renamed
if ($unified_info{rename}->{$d}) {
$d = $unified_info{rename}->{$d};
}
$unified_info{depends}->{$ddest}->{$d} = 1;
Build system: add include directories and dependencies for generators In the case of generating a file like this: GENERATE[foo.S]=mkfoo.pl arg1 arg2 the 'mkfoo.pl' generator itself might need to include other files, such as perl modules within our source tree. We can reuse already existing syntax for it, like this: INCLUDE[mkfoo.pl]=module/path or: DEPEND[mkfoo.pl]=modules/mymodule.pm This change implements the support for such constructs, and for the DEPEND statement, for any value that indicates a perl module (.pm file), it will automatically infer an INCLUDE statement for its directory, just like it does for C header files, so you won't have do write this: DEPEND[mkfoo.pl]=modules/mymodule.pm INCLUDE[mkfoo.pl]=modules Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-04-21 12:30:08 +00:00
# If we depend on a header file or a perl module, let's make
# sure it can get included
if ($d =~ /\.(h|pm)$/) {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $i = dirname($d);
push @{$unified_info{includes}->{$ddest}}, $i
unless grep { $_ eq $i } @{$unified_info{includes}->{$ddest}};
}
}
}
foreach (keys %includes) {
my $dest = $_;
Build system: add include directories and dependencies for generators In the case of generating a file like this: GENERATE[foo.S]=mkfoo.pl arg1 arg2 the 'mkfoo.pl' generator itself might need to include other files, such as perl modules within our source tree. We can reuse already existing syntax for it, like this: INCLUDE[mkfoo.pl]=module/path or: DEPEND[mkfoo.pl]=modules/mymodule.pm This change implements the support for such constructs, and for the DEPEND statement, for any value that indicates a perl module (.pm file), it will automatically infer an INCLUDE statement for its directory, just like it does for C header files, so you won't have do write this: DEPEND[mkfoo.pl]=modules/mymodule.pm INCLUDE[mkfoo.pl]=modules Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-04-21 12:30:08 +00:00
my $ddest = cleanfile($sourced, $_, $blddir);
# If the destination doesn't exist in source, it can only be
# a generated file in the build tree.
if (! -f $ddest) {
$ddest = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$ddest}) {
$ddest = $unified_info{rename}->{$ddest};
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
}
foreach (@{$includes{$dest}}) {
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
my $i = cleandir($sourced, $_, $blddir);
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
push @{$unified_info{includes}->{$ddest}}, $i
unless grep { $_ eq $i } @{$unified_info{includes}->{$ddest}};
}
}
}
### Make unified_info a bit more efficient
# One level structures
Unified - Add the build.info command OVERRIDE, to avoid build file clashes Should it be needed because the recipes within a RAW section might clash with those generated by Configure, it's possible to tell it not to generate them with the use of OVERRIDES, for example: SOURCE[libfoo]=foo.c bar.c OVERRIDES=bar.o BEGINRAW[Makefile(unix)] bar.o: bar.c $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< ENDRAW[Makefile(unix)] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-07 13:50:37 +00:00
foreach (("programs", "libraries", "engines", "scripts", "extra", "overrides")) {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$unified_info{$_} = [ sort keys %{$unified_info{$_}} ];
}
# Two level structures
Make it possible to specify source files that will only be used for shared libs There are rare cases when an object file will only be used when building a shared library. To enable this, we introduce SHARED_SOURCE: SHARED_SOURCE[libfoo]=dllmain.c Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-29 14:45:03 +00:00
foreach my $l1 (("sources", "shared_sources", "ldadd", "depends")) {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
foreach my $l2 (sort keys %{$unified_info{$l1}}) {
$unified_info{$l1}->{$l2} =
[ sort keys %{$unified_info{$l1}->{$l2}} ];
}
}
}
# For the schemes that need it, we provide the old *_obj configs
# from the *_asm_obj ones
Rethink the uplink / applink story 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>
2016-02-18 17:43:56 +00:00
foreach (grep /_(asm|aux)_src$/, keys %target) {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $src = $_;
Rethink the uplink / applink story 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>
2016-02-18 17:43:56 +00:00
(my $obj = $_) =~ s/_(asm|aux)_src$/_obj/;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g;
}
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
# Write down our configuration where it fits #########################
open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n";
print OUT <<"EOF";
package configdata;
use strict;
use warnings;
use Exporter;
#use vars qw(\@ISA \@EXPORT);
our \@ISA = qw(Exporter);
Make apps/progs.pl more flexible Make Configure write @disablables to configdata.pm and have apps/progs.pl use that data. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-18 23:41:14 +00:00
our \@EXPORT = qw(\%config \%target \%disabled \%withargs \%unified_info \@disablables);
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
EOF
print OUT "our %config = (\n";
foreach (sort keys %config) {
if (ref($config{$_}) eq "ARRAY") {
print OUT " ", $_, " => [ ", join(", ",
map { quotify("perl", $_) }
@{$config{$_}}), " ],\n";
} else {
print OUT " ", $_, " => ", quotify("perl", $config{$_}), ",\n"
}
}
print OUT <<"EOF";
);
EOF
print OUT "our %target = (\n";
foreach (sort keys %target) {
if (ref($target{$_}) eq "ARRAY") {
print OUT " ", $_, " => [ ", join(", ",
map { quotify("perl", $_) }
@{$target{$_}}), " ],\n";
} else {
print OUT " ", $_, " => ", quotify("perl", $target{$_}), ",\n"
}
}
print OUT <<"EOF";
);
Use Configure's @disablables and %disabled through configdata.pm Enhances the routines in OpenSSL::Test::Utils for checking disabled stuff to get their information directly from Configure instead of 'openssl list -disabled'. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-26 01:09:33 +00:00
EOF
print OUT "our \%available_protocols = (\n";
print OUT " tls => [ ", join(", ", map { quotify("perl", $_) } @tls), " ],\n";
print OUT " dtls => [ ", join(", ", map { quotify("perl", $_) } @dtls), " ],\n";
print OUT <<"EOF";
);
Make apps/progs.pl more flexible Make Configure write @disablables to configdata.pm and have apps/progs.pl use that data. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-18 23:41:14 +00:00
EOF
print OUT "our \@disablables = (\n";
foreach (@disablables) {
print OUT " ", quotify("perl", $_), ",\n";
}
print OUT <<"EOF";
);
Use Configure's @disablables and %disabled through configdata.pm Enhances the routines in OpenSSL::Test::Utils for checking disabled stuff to get their information directly from Configure instead of 'openssl list -disabled'. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-26 01:09:33 +00:00
EOF
print OUT "our \%disabled = (\n";
foreach (sort keys %disabled) {
print OUT " ", quotify("perl", $_), " => ", quotify("perl", $disabled{$_}), ",\n";
}
print OUT <<"EOF";
);
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
EOF
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
print OUT "our %withargs = (\n";
foreach (sort keys %withargs) {
if (ref($withargs{$_}) eq "ARRAY") {
print OUT " ", $_, " => [ ", join(", ",
map { quotify("perl", $_) }
@{$withargs{$_}}), " ],\n";
} else {
print OUT " ", $_, " => ", quotify("perl", $withargs{$_}), ",\n"
}
}
print OUT <<"EOF";
);
Don't use some object files in FIPS build.
2011-08-23 23:35:30 +00:00
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
EOF
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
if ($builder eq "unified") {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $recurse;
$recurse = sub {
my $indent = shift;
foreach (@_) {
if (ref $_ eq "ARRAY") {
print OUT " "x$indent, "[\n";
foreach (@$_) {
$recurse->($indent + 4, $_);
}
print OUT " "x$indent, "],\n";
} elsif (ref $_ eq "HASH") {
my %h = %$_;
print OUT " "x$indent, "{\n";
foreach (sort keys %h) {
if (ref $h{$_} eq "") {
print OUT " "x($indent + 4), quotify("perl", $_), " => ", quotify("perl", $h{$_}), ",\n";
} else {
print OUT " "x($indent + 4), quotify("perl", $_), " =>\n";
$recurse->($indent + 8, $h{$_});
}
}
print OUT " "x$indent, "},\n";
} else {
print OUT " "x$indent, quotify("perl", $_), ",\n";
}
}
};
print OUT "our %unified_info = (\n";
foreach (sort keys %unified_info) {
if (ref $unified_info{$_} eq "") {
print OUT " "x4, quotify("perl", $_), " => ", quotify("perl", $unified_info{$_}), ",\n";
} else {
print OUT " "x4, quotify("perl", $_), " =>\n";
$recurse->(8, $unified_info{$_});
}
}
print OUT <<"EOF";
);
EOF
}
print OUT "1;\n";
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
close(OUT);
Make Configure work again after eliminating files.
1998-12-28 22:05:44 +00:00
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 13:35:55 +00:00
print "CC =$config{cross_compile_prefix}$target{cc}\n";
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
print "CFLAG =$target{cflags} $config{cflags}\n";
Have Configure display the value of SHARED_CFLAG Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-04 14:41:42 +00:00
print "SHARED_CFLAG =$target{shared_cflag}\n";
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
print "DEFINES =",join(" ", @{$target{defines}}, @{$config{defines}}),"\n";
Minimize copied config settings $target{lflags} and $target{plib_flag} were copied to %config for no good reason. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:42:13 +00:00
print "LFLAG =$target{lflags}\n";
print "PLIB_LFLAG =$target{plib_lflags}\n";
Don't copy from %target to %config so much, see %config as a complement We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-02 09:57:05 +00:00
print "EX_LIBS =$target{ex_libs} $config{ex_libs}\n";
Make uplink auxiliary source separate from cpuid source 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>
2016-03-02 08:34:26 +00:00
print "APPS_OBJ =$target{apps_obj}\n";
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
print "CPUID_OBJ =$target{cpuid_obj}\n";
Make uplink auxiliary source separate from cpuid source 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>
2016-03-02 08:34:26 +00:00
print "UPLINK_OBJ =$target{uplink_obj}\n";
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
print "BN_ASM =$target{bn_obj}\n";
print "EC_ASM =$target{ec_obj}\n";
print "DES_ENC =$target{des_obj}\n";
print "AES_ENC =$target{aes_obj}\n";
print "BF_ENC =$target{bf_obj}\n";
print "CAST_ENC =$target{cast_obj}\n";
print "RC4_ENC =$target{rc4_obj}\n";
print "RC5_ENC =$target{rc5_obj}\n";
print "MD5_OBJ_ASM =$target{md5_obj}\n";
print "SHA1_OBJ_ASM =$target{sha1_obj}\n";
print "RMD160_OBJ_ASM=$target{rmd160_obj}\n";
print "CMLL_ENC =$target{cmll_obj}\n";
print "MODES_OBJ =$target{modes_obj}\n";
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
print "PADLOCK_OBJ =$target{padlock_obj}\n";
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
print "CHACHA_ENC =$target{chacha_obj}\n";
print "POLY1305_OBJ =$target{poly1305_obj}\n";
Add blake2 support. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 22:08:31 +00:00
print "BLAKE2_OBJ =$target{blake2_obj}\n";
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
print "PROCESSOR =$config{processor}\n";
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 13:35:55 +00:00
print "RANLIB =", $target{ranlib} eq '$(CROSS_COMPILE)ranlib' ?
"$config{cross_compile_prefix}ranlib" :
"$target{ranlib}", "\n";
Refactor file writing - introduce template driven file writing 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>
2015-05-18 20:35:23 +00:00
print "ARFLAGS =$target{arflags}\n";
print "PERL =$config{perl}\n";
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
print "\n";
Refactor file writing - rewrite crypto/opensslconf.h.in as template 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>
2015-05-18 23:40:54 +00:00
print "SIXTY_FOUR_BIT_LONG mode\n" if $config{b64l};
print "SIXTY_FOUR_BIT mode\n" if $config{b64};
print "THIRTY_TWO_BIT mode\n" if $config{b32};
print "BN_LLONG mode\n" if $config{bn_ll};
Fix a few Configure errors Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 09:02:13 +00:00
print "RC4 uses $config{rc4_int}\n" if $config{rc4_int} ne $def_int;
Always make links.
1999-03-07 14:05:36 +00:00
Unified build: Keep track of generated header files If someone runs a mixed unixmake / unified environment (the unified build tree would obviously be out of the source tree), the unified build will pick up on the unixmake crypto/buildinf.h because of assumptions made around this sort of declaration (found in crypto/build.info): DEPENDS[cversion.o]=buildinf.h The assumption was that if such a header could be found in the source tree, that was the one to depend on, otherwise it would assume it should be in the build tree. This change makes sure that sort of mix-up won't happen again. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-11 14:22:27 +00:00
for (@generated_headers) {
mkpath(catdir($blddir, dirname($_)));
run_dofile(catfile($blddir, $_),
catfile($srcdir, $_.".in"));
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
###
### When the old "unixmake" scheme goes away, so does this function
###
sub build_Makefile {
run_dofile("Makefile","Makefile.in");
# Copy all Makefile.in to Makefile (except top-level)
use File::Find;
use IO::File;
find(
{
preprocess => sub {
grep(!/^\./, @_);
},
wanted => sub {
return if ($_ ne "Makefile.in" || $File::Find::dir eq ".");
my $in = IO::File->new($_, "r") or
die sprintf "Error reading Makefile.in in %s: !$\n",
$File::Find::dir;
my $out = IO::File->new("Makefile", "w") or
die sprintf "Error writing Makefile in %s: !$\n",
$File::Find::dir;
print $out "# Generated from $_, do not edit\n";
while (my $line = <$in>) { print $out $line }
$in->close() or
die sprintf "Error reading Makefile.in in %s: !$\n",
$File::Find::dir;
$out->close() or
die sprintf "Error writing Makefile in %s: !$\n",
$File::Find::dir;
},
Don't go into dotted directories when copying Makefile.in to Makefile Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-01-31 10:51:07 +00:00
},
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
".");
}
Move Makefiles to Makefile.in Create Makefile's from Makefile.in Rename Makefile.org to Makefile.in Rename Makefiles to Makefile.in Address review feedback from Viktor and Richard Reviewed-by: Viktor Dukhovni <viktor@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-12 21:25:30 +00:00
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
my %builders = (
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
unified => sub {
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
run_dofile(catfile($blddir, $target{build_file}),
$config{build_file_template},
catfile($srcdir, "Configurations", "common.tmpl"));
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
},
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
unixmake => sub {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
build_Makefile();
run_dofile("util/domd", "util/domd.in");
chmod 0755, "util/domd";
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
},
);
unified build scheme: add and document the "unified" driving engine common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-29 23:57:33 +00:00
$builders{$builder}->($builder_platform, @builder_opts);
Strip trailing whitespace from Configure.
2014-05-26 16:19:28 +00:00
Refactor config - a small cosmetic touchup of Configure Start simple, removed some unused variables and change all '<<EOF' to '<<"EOF"'. The latter is because some code colorizers (notably, in emacs) cannot recognise the here document end marker unless it's quoted and therefore assume the rest of the file is part of the here document. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:46:21 +00:00
print <<"EOF";
Re-enable message about transition <foo.h> => <openssl/foo.h> because various programs are not updated that often and hence still expect header files names without the openssl/ prefix.
1999-09-09 20:21:10 +00:00
Print a reassuring message when Configure is done.
2000-02-01 01:35:29 +00:00
Configured for $target.
Re-enable message about transition <foo.h> => <openssl/foo.h> because various programs are not updated that often and hence still expect header files names without the openssl/ prefix.
1999-09-09 20:21:10 +00:00
EOF
New Configure options "threads" and "no-threads". For Solaris and Linux, "threads" (with proper compiler options) is the default. Submitted by: Reviewed by: PR:
1999-04-29 16:10:09 +00:00
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
print <<"EOF" if ($disabled{threads} eq "unavailable");
New Configure options "threads" and "no-threads". For Solaris and Linux, "threads" (with proper compiler options) is the default. Submitted by: Reviewed by: PR:
1999-04-29 16:10:09 +00:00
The library could not be configured for supporting multi-threaded
applications as the compiler options required on this system are not known.
The Mingw32 configuration entry was missing one colon (found by "Zot O'Connor" <zot@ZotConsulting.com>). Also, Windows probably does not need the warning about multi-threading.
1999-06-26 21:25:01 +00:00
See file INSTALL for details if you need multi-threading.
Change #include filenames from <foo.h> to <openssl.h>. Submitted by: Reviewed by: PR:
1999-04-23 22:13:45 +00:00
EOF
Refactor config - a small cosmetic touchup of Configure Start simple, removed some unused variables and change all '<<EOF' to '<<"EOF"'. The latter is because some code colorizers (notably, in emacs) cannot recognise the here document end marker unless it's quoted and therefore assume the rest of the file is part of the here document. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:46:21 +00:00
print <<"EOF" if ($no_shared_warn);
If the user said 'shared' and we haven't included support for shared libraries, warn him or her. Reminder by Andrew Marlow <apm35@student.open.ac.uk>
2003-01-11 11:40:39 +00:00
Introduce the "pic" / "no-pic" config option Building shared libraries or not is not the same as building position independent code or not. It's true that if you don't build PIC, you can't build shared libraries. However, you may very well want to build only static libraries but still want PIC code. Therefore, we introduce a new configuration option "pic", which is enabled by default or explicitely with "enable-pic", or disabled with "no-pic" or "disable-pic". Of course, if "pic" is disabled, "shared" and "dynamic-engine" are automatically disabled as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 01:09:11 +00:00
The options 'shared', 'pic' and 'dynamic-engine' aren't supported on this
platform, so we will pretend you gave the option 'no-pic', which also disables
'shared' and 'dynamic-engine'. If you know how to implement shared libraries
or position independent code, please let us know (but please first make sure
you have tried with a current version of OpenSSL).
Provide better "make depend" warning. Reviewed-by: Matt Caswell <matt@openssl.org>
2015-12-10 17:31:01 +00:00
EOF
Warn when doing an out-of-source build and finding in-source build artifacts The reason to warn is that configuration *may* pick up on configuration header files that are in the source tree, that might be for a wildly different configuration than what is expected in the current out-of-source configuration. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-04-21 16:03:16 +00:00
print <<"EOF" if (-f catfile($srcdir, "configdata.pm") && $srcdir ne $blddir);
WARNING: there are indications that another build was made in the source
directory. This build may have picked up artifacts from that build, the
safest course of action is to clean the source directory and redo this
configuration.
EOF
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
exit(0);
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
######################################################################
#
# Helpers and utility functions
#
# Configuration file reading #########################################
Make picker, thread and combine standard config helper functions Document them as well Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-17 08:09:31 +00:00
# Note: All of the helper functions are for lazy evaluation. They all
# return a CODE ref, which will return the intended value when evaluated.
# Thus, whenever there's mention of a returned value, it's about that
# intended value.
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# Helper function to implement conditional inheritance depending on the
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:10:45 +00:00
# value of $disabled{asm}. Used in inherit_from values as follows:
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
#
# inherit_from => [ "template", asm("asm_tmpl") ]
#
sub asm {
my @x = @_;
sub {
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 13:10:45 +00:00
$disabled{asm} ? () : @x;
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
}
}
Make picker, thread and combine standard config helper functions Document them as well Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-17 08:09:31 +00:00
# Helper function to implement conditional value variants, with a default
# plus additional values based on the value of $config{build_type}.
# Arguments are given in hash table form:
#
# picker(default => "Basic string: ",
# debug => "debug",
# release => "release")
#
# When configuring with --debug, the resulting string will be
# "Basic string: debug", and when not, it will be "Basic string: release"
#
# This can be used to create variants of sets of flags according to the
# build type:
#
# cflags => picker(default => "-Wall",
# debug => "-g -O0",
# release => "-O3")
#
sub picker {
my %opts = @_;
return sub { add($opts{default} || (),
$opts{$config{build_type}} || ())->(); }
}
# Helper function to combine several values of different types into one.
# This is useful if you want to combine a string with the result of a
# lazy function, such as:
#
# cflags => combine("-Wall", sub { $disabled{zlib} ? () : "-DZLIB" })
#
sub combine {
my @stuff = @_;
return sub { add(@stuff)->(); }
}
# Helper function to implement conditional values depending on the value
# of $disabled{threads}. Can be used as follows:
#
# cflags => combine("-Wall", threads("-pthread"))
#
sub threads {
my @flags = @_;
return sub { add($disabled{threads} ? () : @flags)->(); }
}
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
our $add_called = 0;
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
# Helper function to implement adding values to already existing configuration
# values. It handles elements that are ARRAYs, CODEs and scalars
sub _add {
my $separator = shift;
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
# If there's any ARRAY in the collection of values OR the separator
# is undef, we will return an ARRAY of combined values, otherwise a
# string of joined values with $separator as the separator.
my $found_array = !defined($separator);
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
my @values =
map {
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
my $res = $_;
while (ref($res) eq "CODE") {
$res = $res->();
}
if (defined($res)) {
if (ref($res) eq "ARRAY") {
$found_array = 1;
@$res;
} else {
$res;
}
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
} else {
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
();
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
}
} (@_);
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
$add_called = 1;
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
if ($found_array) {
[ @values ];
} else {
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
join($separator, grep { defined($_) && $_ ne "" } @values);
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
}
}
sub add_before {
Configure - neater looking add() and add_before() 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>
2016-02-24 23:17:59 +00:00
my $separator = " ";
if (ref($_[$#_]) eq "HASH") {
my $opts = pop;
$separator = $opts->{separator};
}
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
my @x = @_;
sub { _add($separator, @x, @_) };
}
sub add {
Configure - neater looking add() and add_before() 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>
2016-02-24 23:17:59 +00:00
my $separator = " ";
if (ref($_[$#_]) eq "HASH") {
my $opts = pop;
$separator = $opts->{separator};
}
Refactor config - @MK1MF_Builds out, general build scheme in 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>
2015-05-18 12:31:49 +00:00
my @x = @_;
sub { _add($separator, @_, @x) };
}
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# configuration reader, evaluates the input file as a perl script and expects
# it to fill %targets with target configurations. Those are then added to
# %table.
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 = ();
{
local %table = %::table; # Protect %table from tampering
eval $content;
warn $@ if $@;
}
# For each target, check that it's configured with a hash table.
foreach (keys %targets) {
if (ref($targets{$_}) ne "HASH") {
if (ref($targets{$_}) eq "") {
warn "Deprecated target configuration for $_, ignoring...\n";
} else {
warn "Misconfigured target configuration for $_ (should be a hash table), ignoring...\n";
}
delete $targets{$_};
}
}
%table = (%table, %targets);
}
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# configuration resolver. Will only resolve all the lazy evaluation
# codeblocks for the chosen target and all those it inherits from,
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# recursively
sub resolve_config {
my $target = shift;
my @breadcrumbs = @_;
Comment away the extra checks in Configure The "extra checks" is a debugging tool to check the config resolving mechanism. It uses Perl's smart match, which is experimental and therefore always causes Perl to give out a warning, and it causes older Perl versions to fail entirely. So, it gets commented away, but stays otherwise in place, as it may be useful again. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 16:18:07 +00:00
# my $extra_checks = defined($ENV{CONFIGURE_EXTRA_CHECKS});
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
if (grep { $_ eq $target } @breadcrumbs) {
die "inherit_from loop! target backtrace:\n "
,$target,"\n ",join("\n ", @breadcrumbs),"\n";
}
if (!defined($table{$target})) {
warn "Warning! target $target doesn't exist!\n";
return ();
}
# 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}) {
my @inherit_from =
map { ref($_) eq "CODE" ? $_->() : $_ } @{$table{$target}->{inherit_from}};
foreach (@inherit_from) {
my %inherited_config = resolve_config($_, $target, @breadcrumbs);
# 'template' is a marker that's considered private to
# the config that had it.
delete $inherited_config{template};
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
foreach (keys %inherited_config) {
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
if (!$combined_inheritance{$_}) {
$combined_inheritance{$_} = [];
}
push @{$combined_inheritance{$_}}, $inherited_config{$_};
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
}
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
}
}
# 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
various spelling fixes Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/952)
2016-03-10 20:34:48 +00:00
# empty string, the inherited value list will be run through the
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# 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.
Forgotten change of add() call in Configure Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-26 11:25:13 +00:00
my $default_combiner = add();
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
my %all_keys =
map { $_ => 1 } (keys %combined_inheritance,
keys %{$table{$target}});
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
sub process_values {
my $object = shift;
my $inherited = shift; # Always a [ list ]
my $target = shift;
my $entry = shift;
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
$add_called = 0;
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
while(ref($object) eq "CODE") {
$object = $object->(@$inherited);
}
if (!defined($object)) {
return ();
}
elsif (ref($object) eq "ARRAY") {
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
local $add_called; # To make sure recursive calls don't affect it
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
return [ map { process_values($_, $inherited, $target, $entry) }
@$object ];
} elsif (ref($object) eq "") {
return $object;
} else {
die "cannot handle reference type ",ref($object)
," found in target ",$target," -> ",$entry,"\n";
}
}
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
foreach (sort keys %all_keys) {
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
my $previous = $combined_inheritance{$_};
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
# 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;
}
Configure - Allow CODErefs and ARRAYrefs in configuration setting arrays This provides for more powerful lazy evaluation and buildup of the setting contents. For example, something like this becomes possible: defines => [ sub { $config{thisorthat} ? "FOO" : () } ] Any undefined result of such functions (such as 'undef' or the empty list) will be ignored. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-27 10:08:21 +00:00
$table{$target}->{$_} = process_values($table{$target}->{$_},
$combined_inheritance{$_},
$target, $_);
unless(defined($table{$target}->{$_})) {
delete $table{$target}->{$_};
}
Comment away the extra checks in Configure The "extra checks" is a debugging tool to check the config resolving mechanism. It uses Perl's smart match, which is experimental and therefore always causes Perl to give out a warning, and it causes older Perl versions to fail entirely. So, it gets commented away, but stays otherwise in place, as it may be useful again. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 16:18:07 +00:00
# if ($extra_checks &&
# $previous && !($add_called || $previous ~~ $table{$target}->{$_})) {
# warn "$_ got replaced in $target\n";
# }
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
}
# Finally done, return the result.
return %{$table{$target}};
}
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
sub usage
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
{
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
print STDERR $usage;
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
print STDERR "\npick os/compiler from:\n";
Add strictness, fix variable substition bugs.
1998-12-28 17:08:48 +00:00
my $j=0;
Minor tweaks to keep Perl 5.001 happy.
1999-02-07 18:22:15 +00:00
my $i;
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
my $k=0;
Minor tweaks to keep Perl 5.001 happy.
1999-02-07 18:22:15 +00:00
foreach $i (sort keys %table)
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
{
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
next if $table{$i}->{template};
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
next if $i =~ /^debug/;
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
$k += length($i) + 1;
if ($k > 78)
{
print STDERR "\n";
$k=length($i);
}
print STDERR $i . " ";
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
}
foreach $i (sort keys %table)
{
Refactor config - split read_config into read_config and resolve_config Split the read_config function into read_config that ONLY reads the configuration files but doesn't try to resolve any of the inheritances, and resolve_config which resolves the inheritance chain of a given target. Move them to the bottom of Configure, with the rest of the helpers. Have a new small hash table, %target, which will hold the values for the target the user requested. This also means that all access to the current target data can be reduced from '$table{$target}->{key}' to a mere '$target{key}'. While we're at it, the old string formatted configurations are getting obsolete, so they may as well get deprecated entirely. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-18 00:57:24 +00:00
next if $table{$i}->{template};
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
next if $i !~ /^debug/;
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
$k += length($i) + 1;
if ($k > 78)
{
print STDERR "\n";
$k=length($i);
}
print STDERR $i . " ";
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
}
More compact Configure usage message.
2000-02-21 00:55:45 +00:00
print STDERR "\n\nNOTE: If in doubt, on Unix-ish systems use './config'.\n";
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-24 22:59:36 +00:00
exit(1);
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 10:52:47 +00:00
}
Fix a few Configure errors Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 09:02:13 +00:00
sub run_dofile
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
{
my $out = shift;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my @templates = @_;
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
Templatize util/domd Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-29 18:29:45 +00:00
unlink $out || warn "Can't remove $out, $!"
if -f $out;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
foreach (@templates) {
die "Can't open $_, $!" unless -f $_;
}
Configure: handle spaces in source directory spec RT#4486 Reviewed-by: Matt Caswell <matt@openssl.org>
2016-05-25 09:57:23 +00:00
my $cmd = "$config{perl} \"-I.\" \"-Mconfigdata\" \"$dofile\" -o\"Configure\" \"".join("\" \"",@templates)."\" > \"$out.new\"";
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
#print STDERR "DEBUG[run_dofile]: \$cmd = $cmd\n";
system($cmd);
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
exit 1 if $? != 0;
rename("$out.new", $out) || die "Can't rename $out.new, $!";
}
Configure: pull 'which' back. At earlier point 'which' was replaced with IPC::Cmd::can_run call. Unfortunately on RPM-based systems it is a separate package and it's not given that it's installed. Resurrected 'which' provides poor-man fallback for IPC::Cmd::can_run. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-20 19:31:11 +00:00
sub which
{
my ($name)=@_;
if (eval { require IPC::Cmd; 1; }) {
IPC::Cmd->import();
return scalar IPC::Cmd::can_run($name);
} else {
# if there is $directories component in splitpath,
# then it's not something to test with $PATH...
return $name if (File::Spec->splitpath($name))[1];
foreach (File::Spec->path()) {
my $fullpath = catfile($_, "$name$target{exe_extension}");
if (-f $fullpath and -x $fullpath) {
return $fullpath;
}
}
}
}
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
# Configuration printer ##############################################
sub print_table_entry
{
my $target = shift;
my %target = resolve_config($target);
my $type = shift;
# Don't print the templates
return if $target{template};
my @sequence = (
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
"sys_id",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"cc",
"cflags",
Configure et al: treat C defines separately 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>
2016-01-30 01:17:05 +00:00
"defines",
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
"unistd",
"ld",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"lflags",
Enhance and clear the support of linker flags Some time ago, we had a ex_libs configuration setting that could be divided into lflags and ex_libs. These got divided in two settings, lflags and ex_libs, and the former was interpreted to be general linking flags. Unfortunately, that conclusion wasn't entirely accurate. Most of those linking were meant to end up in a very precise position on the linking command line, just before the spec of libraries the linking depends on. Back to the drawing board, we're diving things further, now having lflags, which are linking flags that aren't depending on command line position, plib_lflags, which are linking flags that should show up just before the spec of libraries to depend on, and finally ex_libs, which is the spec of extra libraries to depend on. Also, documentation is changed in Configurations/README. This was previously forgotten. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-02-05 10:47:14 +00:00
"plib_lflags",
Configure et al: split up the lflags configuration item into two The lflags configuration had a weird syntax with a % as separator. If it was present, whatever came before ended up as PEX_LIBS in Makefile (usually, this is LDFLAGS), while whatever came after ended up as EX_LIBS. This change splits that item into lflags and ex_libs, making their use more explicit. Also, PEX_LIBS in all the Makefiles are renamed to LDFLAGS. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-01-29 17:07:37 +00:00
"ex_libs",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"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",
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
"padlock_obj",
Configure - Get rid of the special thread_cflag, replace with thread_scheme 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>
2016-02-27 15:51:34 +00:00
"thread_scheme",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"perlasm_scheme",
"dso_scheme",
"shared_target",
"shared_cflag",
"shared_ldflag",
Add support for shared_rcflag, useful for windres (Cygwin and Mingw) Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-05 14:17:33 +00:00
"shared_rcflag",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"shared_extension",
Let Configure figure out the diverse shared library and DSO extensions Then it can pass around the information where it belongs. The Makefile templates pick it up along with other target data, the DSO module gets to pick up the information through crypto/include/internal/dso_conf.h Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-15 16:20:15 +00:00
"shared_extension_simple",
"shared_import_extension",
"dso_extension",
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
"obj_extension",
"exe_extension",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"ranlib",
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
"ar",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
"arflags",
"multilib",
Small cleanups in Configure - 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>
2016-01-25 20:51:22 +00:00
"build_scheme",
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
);
if ($type eq "TABLE") {
print "\n";
print "*** $target\n";
Make the table entry printer in Configure aware of ARRAYs Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-24 00:32:51 +00:00
foreach (@sequence) {
if (ref($target{$_}) eq "ARRAY") {
printf "\$%-12s = %s\n", $_, join(" ", @{$target{$_}});
} else {
printf "\$%-12s = %s\n", $_, $target{$_};
}
}
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
} elsif ($type eq "HASH") {
my $largest =
length((sort { length($a) <=> length($b) } @sequence)[-1]);
print " '$target' => {\n";
foreach (@sequence) {
if ($target{$_}) {
Make the table entry printer in Configure aware of ARRAYs Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-24 00:32:51 +00:00
if (ref($target{$_}) eq "ARRAY") {
print " '",$_,"'"," " x ($largest - length($_))," => [ ",join(", ", map { "'$_'" } @{$target{$_}})," ],\n";
} else {
print " '",$_,"'"," " x ($largest - length($_))," => '",$target{$_},"',\n";
}
Refactor config - consolidate and refresh print_table_entry 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>
2015-05-18 10:53:38 +00:00
}
}
print " },\n";
}
}
# Utility routines ###################################################
Make the processing of build.info files more aware of absolute dirs There were cases where some input was absolute, and concatenating it to the diretory to the source or build top could fail spectacularly. Let's check the input first to see if it's absolute. And while we're on the subject of checking if a file or dir spec is absolute using file_name_is_absolute() has its own quirks on VMS, where a logical name is considered absolute under most circumstances. This is perfectly correct from a VMS point of view, but when parsing the build.info files, we want single word file or directory names to only be checked syntactically. A function isabsolute() that does the right thing is the solution. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 01:00:37 +00:00
# On VMS, if the given file is a logical name, File::Spec::Functions
# will consider it an absolute path. There are cases when we want a
# purely syntactic check without checking the environment.
sub isabsolute {
my $file = shift;
# On non-platforms, we just use file_name_is_absolute().
return file_name_is_absolute($file) unless $^O eq "VMS";
# If the file spec includes a device or a directpry spec,
# file_name_is_absolute() is perfectly safe.
return file_name_is_absolute($file) if $file =~ m|[:\[]|;
# Here, we know the given file spec isn't absolute
return 0;
}
Use rel2abs() on VMS, rather than realpath() It seems realpath() is quite buggy on VMS, or will at least give quite surprising results. On the other hand, realpath() is the better on Unix to clean out clutter like foo/../bar on Unix. So we make out own function to get the absolute directory for a given input, and use rel2abs() or realpath() depending on the platform Configure runs on. Issue reported by Steven M. Schweda <sms@antinode.info> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-09 09:15:13 +00:00
# Makes a directory absolute and cleans out /../ in paths like foo/../bar
# On some platforms, this uses rel2abs(), while on others, realpath() is used.
# realpath() requires that at least all path components except the last is an
# existing directory. On VMS, the last component of the directory spec must
# exist.
sub absolutedir {
my $dir = shift;
# realpath() is quite buggy on VMS. It uses LIB$FID_TO_NAME, which
# will return the volume name for the device, no matter what. Also,
# it will return an incorrect directory spec if the argument is a
# directory that doesn't exist.
if ($^O eq "VMS") {
return rel2abs($dir);
}
# We use realpath() on Unix, since no other will properly clean out
# a directory spec.
use Cwd qw/realpath/;
return realpath($dir);
}
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
sub quotify {
my %processors = (
perl => sub { my $x = shift;
$x =~ s/([\\\$\@"])/\\$1/g;
return '"'.$x.'"'; },
);
my $for = shift;
my $processor =
defined($processors{$for}) ? $processors{$for} : sub { shift; };
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
return map { $processor->($_); } @_;
Refactor config - rewrite handling of "reconf" The way the "reconf"/"reconfigure" argument is handled is overly complicated. Just grep for it first, and if it is there in the current arguments, get the old command line arguments from Makefile. While we're at it, make the Makefile variable CONFIGURE_ARGS hold the value as a perl list of strings. This makes things much safer in case one of the arguments would contain a space. Since CONFIGURE_ARGS is used for nothing else, there's no harm in this. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2015-05-18 01:33:55 +00:00
}
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
# collect_from_file($filename, $line_concat_cond_re, $line_concat)
# $filename is a file name to read from
# $line_concat_cond_re is a regexp detecting a line continuation ending
# $line_concat is a CODEref that takes care of concatenating two lines
sub collect_from_file {
my $filename = shift;
my $line_concat_cond_re = shift;
my $line_concat = shift;
open my $fh, $filename || die "unable to read $filename: $!\n";
return sub {
my $saved_line = "";
$_ = "";
while (<$fh>) {
Remove last chomps In the previous commit to change all chomp to a more flexible regexp, Configure was forgotten. This completes the change. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-12 11:10:27 +00:00
s|\R$||;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if (defined $line_concat) {
$_ = $line_concat->($saved_line, $_);
$saved_line = "";
}
if (defined $line_concat_cond_re && /$line_concat_cond_re/) {
$saved_line = $_;
next;
}
return $_;
}
die "$filename ending with continuation line\n" if $_;
close $fh;
return undef;
}
}
# collect_from_array($array, $line_concat_cond_re, $line_concat)
# $array is an ARRAYref of lines
# $line_concat_cond_re is a regexp detecting a line continuation ending
# $line_concat is a CODEref that takes care of concatenating two lines
sub collect_from_array {
my $array = shift;
my $line_concat_cond_re = shift;
my $line_concat = shift;
my @array = (@$array);
return sub {
my $saved_line = "";
$_ = "";
while (defined($_ = shift @array)) {
Remove last chomps In the previous commit to change all chomp to a more flexible regexp, Configure was forgotten. This completes the change. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-12 11:10:27 +00:00
s|\R$||;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
if (defined $line_concat) {
$_ = $line_concat->($saved_line, $_);
$saved_line = "";
}
if (defined $line_concat_cond_re && /$line_concat_cond_re/) {
$saved_line = $_;
next;
}
return $_;
}
die "input text ending with continuation line\n" if $_;
return undef;
}
}
# collect_information($lineiterator, $line_continue, $regexp => $CODEref, ...)
# $lineiterator is a CODEref that delivers one line at a time.
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
# All following arguments are regex/CODEref pairs, where the regexp detects a
# line and the CODEref does something with the result of the regexp.
sub collect_information {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $lineiterator = shift;
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
my %collectors = @_;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
while(defined($_ = $lineiterator->())) {
Remove last chomps In the previous commit to change all chomp to a more flexible regexp, Configure was forgotten. This completes the change. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-12 11:10:27 +00:00
s|\R$||;
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
my $found = 0;
Added build.info debugging capability to Configure This is only enabled when the environment variable CONFIGURE_DEBUG_BUILDINFO is defined. This will cause every line in every build.info file to be displayed, along with the content of the skip stack before and after parsing. This can be a very powerful tool to see that all conditions are working as expected. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 23:04:04 +00:00
if ($collectors{"BEFORE"}) {
$collectors{"BEFORE"}->($_);
}
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
foreach my $re (keys %collectors) {
Added build.info debugging capability to Configure This is only enabled when the environment variable CONFIGURE_DEBUG_BUILDINFO is defined. This will cause every line in every build.info file to be displayed, along with the content of the skip stack before and after parsing. This can be a very powerful tool to see that all conditions are working as expected. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 23:04:04 +00:00
if ($re !~ /^OTHERWISE|BEFORE|AFTER$/ && /$re/) {
unified build scheme: a first introduction 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>
2016-01-29 18:45:51 +00:00
$collectors{$re}->($lineiterator);
$found = 1;
};
}
if ($collectors{"OTHERWISE"}) {
$collectors{"OTHERWISE"}->($lineiterator, $_)
unless $found || !defined $collectors{"OTHERWISE"};
}
Added build.info debugging capability to Configure This is only enabled when the environment variable CONFIGURE_DEBUG_BUILDINFO is defined. This will cause every line in every build.info file to be displayed, along with the content of the skip stack before and after parsing. This can be a very powerful tool to see that all conditions are working as expected. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09 23:04:04 +00:00
if ($collectors{"AFTER"}) {
$collectors{"AFTER"}->($_);
}
Refactor file writing - Remake Makefile.org into a template 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>
2015-05-20 18:03:20 +00:00
}
}
Configure: To allow file names with spaces, tokenize with respect for quotes For parsing build.info files. RT#4492 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-05-24 15:39:52 +00:00
# tokenize($line)
# $line is a line of text to split up into tokens
# returns a list of tokens
#
# Tokens are divided by spaces. If the tokens include spaces, they
# have to be quoted with single or double quotes. Double quotes
# inside a double quoted token must be escaped. Escaping is done
# with backslash.
# Basically, the same quoting rules apply for " and ' as in any
# Unix shell.
sub tokenize {
my $line = my $debug_line = shift;
my @result = ();
while ($line =~ s|^\s+||, $line ne "") {
my $token = "";
while ($line ne "" && $line !~ m|^\s|) {
if ($line =~ m/^"((?:[^"\\]+|\\.)*)"/) {
$token .= $1;
$line = $';
} elsif ($line =~ m/^'([^']*)'/) {
$token .= $1;
$line = $';
} elsif ($line =~ m/^(\S+)/) {
$token .= $1;
$line = $';
}
}
push @result, $token;
}
if ($ENV{CONFIGURE_DEBUG_TOKENIZE}) {
print STDERR "DEBUG[tokenize]: Parsed '$debug_line' into:\n";
print STDERR "DEBUG[tokenize]: ('", join("', '", @result), "')\n";
}
return @result;
}
Reference in a new issue Copy permalink