mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-27 05:21:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
f90486f4de
openssl/Configure

2825 lines
92 KiB
Plaintext
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 21:06:45 +08: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 13:44:58 +08:00
# -*- mode: perl; -*-
Implementation of the ARIA cipher as described in RFC 5794. This implementation is written in endian agnostic C code. No attempt at providing machine specific assembly code has been made. This implementation expands the evptests by including the test cases from RFC 5794 and ARIA official site rather than providing an individual test case. Support for ARIA has been integrated into the command line applications, but not TLS. Implemented modes are CBC, CFB1, CFB8, CFB128, CTR, ECB and OFB128. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2337)
2017-02-01 08:10:13 +08:00
# Copyright 2016-2017 The OpenSSL Project Authors. All Rights Reserved.
Copyright consolidation; .pm and Configure Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-20 22:20:59 +08:00
#
# 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 21:06:45 +08: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 16:48:52 +08:00
## Configure -- OpenSSL source tree configuration script
Add strictness, fix variable substition bugs.
1998-12-29 01:08:48 +08:00
Configure: use 5.10.0, don't require... Configure started with 'require 5.10.0', but if executed by older perl it failed with "might be runaway multi-line // string" instead of naturally expected "Perl v5.10.0 required--this is only v5.x.y". Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-03-31 20:37:10 +08:00
use 5.10.0;
Add strictness, fix variable substition bugs.
1998-12-29 01:08:48 +08:00
use strict;
Trim config output With extensive help and feedback from Richard and Andy. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-07 00:26:38 +08:00
use Config;
Consolidate the locations where we have our internal perl modules Instead of having perl modules under test/testlib, util and util/perl, consolidate them all to be inside util/perl. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4069)
2017-08-02 04:10:39 +08:00
use FindBin;
use lib "$FindBin::Bin/util/perl";
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-25 06:40:22 +08: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-03 02:47:05 +08: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 23:27:15 +08:00
use File::Path qw/mkpath/;
File::Glob option ':bsd_glob' doesn't work everywhere, replace w/ a wrapper Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4069)
2017-08-02 04:43:56 +08:00
use OpenSSL::Glob;
Add strictness, fix variable substition bugs.
1998-12-29 01:08:48 +08:00
Defunct assembler files removed; various cleanups. New Ultrix and Alpha entries submitted by Bernhard Simon <simon@zid.tuwien.ac.at>.
1999-04-19 21:54:11 +08:00
# see INSTALL for instructions.
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-11 00:10:39 +08: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-25 06:59:36 +08:00
Document additional Configure flags.
1999-04-19 23:19:58 +08:00
# Options:
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-30 05:52:08 +08: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-25 06:40:22 +08: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-21 01:11:51 +08: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-30 05:52:08 +08:00
#
Rudimentary support for cross-compiling.
2006-10-21 21:38:16 +08: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 12:00:33 +08: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-27 05:07:28 +08: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-30 00:10:09 +08: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 12:19:50 +08: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 09:09:11 +08: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 22:57:25 +08:00
# If disabled, it also disables shared and dynamic-engine.
Error in comment.
1999-04-19 22:55:56 +08: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 15:09:45 +08: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 08:02:16 +08: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 17:11:14 +08: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 22:45:15 +08:00
# sctp include SCTP support
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 23:40:51 +08:00
# enable-weak-ssl-ciphers
Remove non-accurate description in Configure script For DES and 3DES based ciphers are also enabled by this option. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3707)
2017-06-17 22:17:44 +08:00
# Enable weak ciphers that are disabled by default.
INSTALL: clarify 386 and no-sse2 options. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-11-21 04:52:41 +08:00
# 386 generate 80386 code in assembly modules
# no-sse2 disables IA-32 SSE2 code in assembly modules, the above
# mentioned '386' option implies this one
New Configure option no-<cipher> (rsa, idea, rc5, ...).
1999-04-27 11:19:12 +08:00
# no-<cipher> build without specified algorithm (rsa, idea, rc5, ...)
Strip trailing whitespace from Configure.
2014-05-27 00:19:28 +08:00
# -<xxx> +<xxx> compiler options are passed through
Configure: clarify and refine -static. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-09-02 03:36:13 +08:00
# -static while -static is also a pass-through compiler option (and
# as such is limited to environments where it's actually
# meaningful), it triggers a number configuration options,
# namely no-dso, no-pic, no-shared and no-threads. It is
# argued that the only reason to produce statically linked
# binaries (and in context it means executables linked with
# -static flag, and not just executables linked with static
# libcrypto.a) is to eliminate dependency on specific run-time,
# a.k.a. libc version. The mentioned config options are meant
# to achieve just that. Unfortunately on Linux it's impossible
# to eliminate the dependency completely for openssl executable
# because of getaddrinfo and gethostbyname calls, which can
# invoke dynamically loadable library facility anyway to meet
# the lookup requests. For this reason on Linux statically
# linked openssl executable has rather debugging value than
# production quality.
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 13:13:52 +08: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 18:52:47 +08: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-19 00:19:34 +08: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-11 04:34:48 +08: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-19 00:19:34 +08:00
# SHA256_ASM sha256_block is implemented in assembler
# SHA512_ASM sha512_block is implemented in assembler
Fix typo Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1241)
2016-06-21 19:30:54 +08:00
# AES_ASM AES_[en|de]crypt is implemented in assembler
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 23:56:32 +08:00
# Minimum warning options... any contributions to OpenSSL should at least get
Strip trailing whitespace from Configure.
2014-05-27 00:19:28 +08: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 23:56:32 +08: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 18:47:35 +08:00
# DEBUG_UNUSED enables __owur (warn unused result) checks.
Add -Wno-parentheses-equality to dev-warnings. Also fix a block comment formatting glitch. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2327)
2017-01-31 05:13:41 +08:00
# -DPEDANTIC complements -pedantic and is meant to mask code that
# is not strictly standard-compliant and/or implementation-specific,
# 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.
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 18:47:35 +08:00
my $gcc_devteam_warn = "-DDEBUG_UNUSED"
. " -DPEDANTIC -pedantic -Wno-long-long"
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 01:27:11 +08:00
. " -Wall"
Add -Wextra to gcc devteam warnings clang already has it; let's flip the switch and deal with the fallout. Exclude -Wunused-parameter, as we have many places where we keep unused parameters to conform to a uniform vtable-like interface. Also exclude -Wmissing-field-initializers; it's okay to rely on the standard-mandated behavior of filling out with 0/NULL. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3239)
2017-04-18 23:48:11 +08:00
. " -Wextra"
. " -Wno-unused-parameter"
. " -Wno-missing-field-initializers"
Configure: base compiler-specific decisions on pre-defines. The commit subject is a bit misleading in sense that decisions affect only gcc and gcc-alikes, like clang, recent icc... Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4281)
2017-08-29 21:47:08 +08:00
. " -Wswitch"
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 01:27:11 +08:00
. " -Wsign-compare"
. " -Wmissing-prototypes"
. " -Wshadow"
. " -Wformat"
. " -Wtype-limits"
Add -Wundef to --strict-warnings options. Avoid a -Wundef warning in refcount.h Avoid a -Wundef warning in o_str.c Avoid a -Wundef warning in testutil.h Include internal/cryptlib.h before openssl/stack.h to avoid use of undefined symbol OPENSSL_API_COMPAT. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2712)
2017-02-23 21:52:23 +08:00
. " -Wundef"
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 01:27:11 +08:00
. " -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 23:56:32 +08:00
Fix build on MacOS. Reviewed-by: Andy Polyakov
2015-04-19 21:10:54 +08: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 09:45:44 +08:00
# following warnings can also be enabled:
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 01:27:11 +08:00
# -Wcast-align
Add -Wno-parentheses-equality to dev-warnings. Also fix a block comment formatting glitch. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2327)
2017-01-31 05:13:41 +08:00
# -Wunreachable-code -- no, too ugly/compiler-specific
Remove unused parameters from internal functions Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 11:33:56 +08: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-14 01:27:11 +08:00
my $clang_devteam_warn = ""
. " -Qunused-arguments"
Remove duplicates from clang_devteam_warnings Since the clang_devteam_warnings are appended to the gcc_devteam_warnings when strict-warnings are requested, any items present in both the gcc and clang variables will be duplicated in the cflags used for clang builds. Remove the extra copy from the clang-specific flags in favor of the gcc_devteam_warnings that are used for all strict-warnings builds. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3239)
2017-05-02 01:39:20 +08:00
. " -Wswitch-default"
Add -Wno-parentheses-equality to dev-warnings. Also fix a block comment formatting glitch. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2327)
2017-01-31 05:13:41 +08:00
. " -Wno-parentheses-equality"
Reformat warn variables for easier editing. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 01:27:11 +08:00
. " -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 20:46:26 +08: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 19:16:52 +08: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-03 01:44:26 +08:00
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-10 00:31:32 +08: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 22:38:14 +08:00
# As for $BSDthreads. Idea is to maintain "collective" set of flags,
Strip trailing whitespace from Configure.
2014-05-27 00:19:28 +08: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 22:38:14 +08: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 23:51:34 +08:00
our $BSDthreads="-pthread -D_THREAD_SAFE -D_REENTRANT";
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 12:00:33 +08:00
#
Spelling... and more spelling Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1245)
2016-06-20 01:39:01 +08:00
# API compatibility name to version number mapping.
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 12:00:33 +08:00
#
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 08:54:28 +08: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-19 04:35:23 +08: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 18:37:33 +08:00
our %withargs = ();
Add the configuration target VxWorks.
2002-02-14 23:37:38 +08: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 08:57:24 +08:00
# Forward declarations ###############################################
Configure: fold related configurations more aggressively and clean-up. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-03-17 05:33:36 +08: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 08:57:24 +08: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 17:01:08 +08: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 08:57:24 +08: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-11 04:34:48 +08: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 08:57:24 +08: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 17:01:08 +08:00
Update from 1.0.0-stable
2009-07-01 19:46:03 +08: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-21 02:03:20 +08: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-30 02:45:51 +08: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 17:15:13 +08: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-30 02:45:51 +08: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 22:50:51 +08: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-30 02:45:51 +08:00
$config{sourcedir} = abs2rel($srcdir);
$config{builddir} = abs2rel($blddir);
Configure: save away the value of OPENSSL_LOCAL_CONFIG_DIR for reconf Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-30 04:11:36 +08:00
# Collect reconfiguration information if needed
my @argvcopy=@ARGV;
if (grep /^reconf(igure)?$/, @argvcopy) {
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;
}
@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{CC} = $configdata::config{cc}
if defined($configdata::config{cc});
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
$ENV{CXX} = $configdata::config{cxx}
if defined($configdata::config{cxx});
Configure: save away the value of OPENSSL_LOCAL_CONFIG_DIR for reconf Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-30 04:11:36 +08:00
$ENV{BUILDFILE} = $configdata::config{build_file}
if defined($configdata::config{build_file});
$ENV{$local_config_envname} = $configdata::config{local_config_dir}
if defined($configdata::config{local_config_dir});
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};
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
print " CXX = ",$ENV{CXX},"\n" if $ENV{CXX};
Configure: save away the value of OPENSSL_LOCAL_CONFIG_DIR for reconf Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-30 04:11:36 +08:00
print " BUILDFILE = ",$ENV{BUILDFILE},"\n" if $ENV{BUILDFILE};
print " $local_config_envname = ",$ENV{$local_config_envname},"\n"
if $ENV{$local_config_envname};
} else {
die "Insufficient data to reconfigure, please do a normal configuration\n";
}
}
$config{perlargv} = [ @argvcopy ];
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-21 02:03:20 +08: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-30 02:45:51 +08: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-21 02:03:20 +08: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-03 02:47:05 +08: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 22:11:01 +08: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-25 06:40:22 +08:00
&read_config($_);
}
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 22:50:51 +08: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 22:11:01 +08: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 22:50:51 +08: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-19 04:35:23 +08: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-19 07:40:54 +08: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-21 02:03:20 +08: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 09:27:30 +08:00
$config{cross_compile_prefix}="";
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 23:51:34 +08: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 21:04:06 +08: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-21 02:03:20 +08:00
# Top level directories to build
Allow asan, msan and ubsan to be configured with shared libraries The background story is that util/shlib_wrap.sh was setting LD_PRELOAD or similar platform dependent variables, just in case the shared libraries were built with -rpath. Unfortunately, this doesn't work too well with asan, msan or ubsan. So, the solution is to forbid the combination of shared libraries, -rpath and any of the sanity analyzers we can configure. This changes util/shlib_wrap.sh so it only contains the code that sets LD_PRELOAD when -rpath has been used when configuring. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-08 02:56:20 +08:00
$config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "util", "tools", "fuzz" ];
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-21 02:03:20 +08:00
# crypto/ subdirectories to build
$config{sdirs} = [
"objects",
Add support for parameterized SipHash The core SipHash supports either 8 or 16-byte output and a configurable number of rounds. The default behavior, as added to EVP, is to use 16-byte output and 2,4 rounds, which matches the behavior of most implementations. There is an EVP_PKEY_CTRL that can control the output size. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2216)
2017-01-12 05:38:44 +08:00
"md2", "md4", "md5", "sha", "mdc2", "hmac", "ripemd", "whrlpool", "poly1305", "blake2", "siphash",
Implementation of the ARIA cipher as described in RFC 5794. This implementation is written in endian agnostic C code. No attempt at providing machine specific assembly code has been made. This implementation expands the evptests by including the test cases from RFC 5794 and ARIA official site rather than providing an individual test case. Support for ARIA has been integrated into the command line applications, but not TLS. Implemented modes are CBC, CFB1, CFB8, CFB128, CTR, ECB and OFB128. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2337)
2017-02-01 08:10:13 +08:00
"des", "aes", "rc2", "rc4", "rc5", "idea", "aria", "bf", "cast", "camellia", "seed", "chacha", "modes",
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-21 02:03:20 +08:00
"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",
Add the STORE module This STORE module adds the following functionality: - A function OSSL_STORE_open(), OSSL_STORE_load() and OSSL_STORE_close() that accesses a URI and helps loading the supported objects (PKEYs, CERTs and CRLs for the moment) from it. - An opaque type OSSL_STORE_INFO that holds information on each loaded object. - A few functions to retrieve desired data from a OSSL_STORE_INFO reference. - Functions to register and unregister loaders for different URI schemes. This enables dynamic addition of loaders from applications or from engines. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3542)
2016-12-08 22:51:31 +08:00
"cms", "ts", "srp", "cmac", "ct", "async", "kdf", "store"
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-21 02:03:20 +08:00
];
Integrate ossl_shim into the build Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-10-12 23:05:06 +08:00
# test/ subdirectories to build
$config{tdirs} = [ "ossl_shim" ];
New Makefile variables $(RANLIB) and $(PERL).
1999-04-01 20:34:33 +08: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-19 02:10:21 +08:00
# Known TLS and DTLS protocols
Update Configure to know about tls1_3 Also we disable TLS1.3 by default (use enable-tls1_3 to re-enable). This is because this is a WIP and will not be interoperable with any other TLS1.3 implementation. Finally, we fix some tests that started failing when TLS1.3 was disabled by default. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-30 16:38:52 +08:00
my @tls = qw(ssl3 tls1 tls1_1 tls1_2 tls1_3);
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-19 02:10:21 +08:00
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-11 04:34:48 +08: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 23:09:14 +08: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 19:21:44 +08:00
"afalgeng",
Implementation of the ARIA cipher as described in RFC 5794. This implementation is written in endian agnostic C code. No attempt at providing machine specific assembly code has been made. This implementation expands the evptests by including the test cases from RFC 5794 and ARIA official site rather than providing an individual test case. Support for ARIA has been integrated into the command line applications, but not TLS. Implemented modes are CBC, CFB1, CFB8, CFB128, CTR, ECB and OFB128. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2337)
2017-02-01 08:10:13 +08:00
"aria",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08: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 23:09:14 +08: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-05 00:41:25 +08: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 19:26:14 +08: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 17:39:07 +08: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 23:09:14 +08:00
"bf",
Add blake2 support. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-10 06:08:31 +08: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 23:09:14 +08:00
"camellia",
"capieng",
"cast",
Configure: make no-chacha and no-poly1305 work. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-10 06:02:11 +08: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 23:09:14 +08: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-10 06:55:57 +08: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 19:16:52 +08: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 23:09:14 +08:00
"ct",
"deprecated",
"des",
Add new /dev/crypto engine Based on cryptodev-linux Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3744)
2017-03-24 23:19:00 +08:00
"devcryptoeng",
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 23:09:14 +08:00
"dgram",
"dh",
"dsa",
"dso",
Use OPENSSL_NO_DTLS instead of OPENSSL_NO_DTLS1 Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-12 18:12:22 +08: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-20 05:08:37 +08: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 23:09:14 +08: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-19 02:10:21 +08: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 23:09:14 +08: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-04 04:08:17 +08: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 23:09:14 +08: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-18 02:33:51 +08:00
"err",
Control building of ossl_shim through Configure Don't build ossl_shim by default. Switch it on through enable-external-tests. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-10-12 23:21:13 +08:00
"external-tests",
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 18:45:25 +08:00
"filenames",
Add support for fuzzing with AFL Reviewed-by: Ben Laurie <ben@links.org> MR: #2740
2016-05-08 04:09:13 +08:00
"fuzz-libfuzzer",
"fuzz-afl",
Fix no-gost Configure had the wrong name for the no-gost option. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-21 23:04:08 +08:00
"gost",
Revert "Remove heartbeats completely" Done too soon, this is for future OpenSSL 1.2.0 This reverts commit 6c62f9e1639a7d1a879f363a99882920104dfedb. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-15 21:53:33 +08:00
"heartbeats",
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 23:09:14 +08:00
"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 08:14:29 +08: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 23:09:14 +08:00
"md2",
"md4",
"mdc2",
Add memory sanitizer config, and run on travis. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-29 02:24:28 +08:00
"msan",
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-08 07:26:32 +08: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 23:09:14 +08: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 09:09:11 +08:00
"pic",
Configure: make no-chacha and no-poly1305 work. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-10 06:02:11 +08: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 23:09:14 +08:00
"posix-io",
"psk",
"rc2",
"rc4",
"rc5",
"rdrand",
"rfc3779",
"rmd160",
"scrypt",
"sctp",
"seed",
"shared",
Add support for parameterized SipHash The core SipHash supports either 8 or 16-byte output and a configurable number of rounds. The default behavior, as added to EVP, is to use 16-byte output and 2,4 rounds, which matches the behavior of most implementations. There is an EVP_PKEY_CTRL that can control the output size. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2216)
2017-01-12 05:38:44 +08:00
"siphash",
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 23:09:14 +08:00
"sock",
"srp",
"srtp",
"sse2",
"ssl",
"ssl-trace",
"static-engine",
"stdio",
Make it possible to disable building and running tests Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1514)
2016-08-30 12:02:50 +08:00
"tests",
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 23:09:14 +08:00
"threads",
"tls",
Make the TLSv1.3 downgrade mechanism a configurable option Make it disabled by default. When TLSv1.3 is out of draft we can remove this option and have it enabled all the time. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3022)
2017-03-22 19:52:45 +08:00
"tls13downgrade",
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-18 02:33:51 +08:00
"ts",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08:00
"ubsan",
Remove the possibility to disable the UI module entirely Instead, make it possible to disable the console reader that's part of the UI module. This makes it possible to use the UI API and other UI methods in environments where the console reader isn't useful. To disable the console reader, configure with 'no-ui-console' / 'disable-ui-console'. 'no-ui' / 'disable-ui' is now an alias for 'no-ui-console' / 'disable-ui-console'. Fixes #3806 Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3820)
2017-07-01 18:14:37 +08:00
"ui-console",
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 23:09:14 +08: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 23:40:51 +08: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 23:09:14 +08: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-19 02:10:21 +08:00
foreach my $proto ((@tls, @dtls))
{
push(@disablables, $proto);
Drop support for OPENSSL_NO_TLS1_3_METHOD There are no public TLSv1_3_*method() functions so OPENSSL_NO_TLS1_3_METHOD doesn't make any sense and should be removed. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3800)
2017-06-29 22:03:14 +08:00
push(@disablables, "$proto-method") unless $proto eq "tls1_3";
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-19 02:10:21 +08:00
}
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 23:09:14 +08:00
no-ripemd is an alias for no-rmd160 mkdef.pl was failing to understand no-ripemd. This is a deprecated option which should act as an alias for no-rmd160. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-16 18:45:24 +08:00
my %deprecated_disablables = (
"ssl2" => undef,
"buf-freelists" => undef,
Remove the possibility to disable the UI module entirely Instead, make it possible to disable the console reader that's part of the UI module. This makes it possible to use the UI API and other UI methods in environments where the console reader isn't useful. To disable the console reader, configure with 'no-ui-console' / 'disable-ui-console'. 'no-ui' / 'disable-ui' is now an alias for 'no-ui-console' / 'disable-ui-console'. Fixes #3806 Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3820)
2017-07-01 18:14:37 +08:00
"ripemd" => "rmd160",
"ui" => "ui-console",
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 17:42:53 +08: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 18:29:51 +08: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 20:45:46 +08:00
our %disabled = ( # "what" => "comment"
Implementation of the ARIA cipher as described in RFC 5794. This implementation is written in endian agnostic C code. No attempt at providing machine specific assembly code has been made. This implementation expands the evptests by including the test cases from RFC 5794 and ARIA official site rather than providing an individual test case. Support for ARIA has been integrated into the command line applications, but not TLS. Implemented modes are CBC, CFB1, CFB8, CFB128, CTR, ECB and OFB128. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2337)
2017-02-01 08:10:13 +08:00
"aria" => "default",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08:00
"asan" => "default",
Sort %disabled in Configure @disablables is sorted, but these were just added at the end of %disabled in commits c2e27310 and 22e3dcb7. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-08-19 04:47:04 +08:00
"crypto-mdebug" => "default",
"crypto-mdebug-backtrace" => "default",
Add new /dev/crypto engine Based on cryptodev-linux Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3744)
2017-03-24 23:19:00 +08:00
"devcryptoeng" => "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 20:45:46 +08: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 23:40:51 +08:00
"egd" => "default",
Control building of ossl_shim through Configure Don't build ossl_shim by default. Switch it on through enable-external-tests. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-10-12 23:21:13 +08:00
"external-tests" => "default",
Add support for fuzzing with AFL Reviewed-by: Ben Laurie <ben@links.org> MR: #2740
2016-05-08 04:09:13 +08:00
"fuzz-libfuzzer" => "default",
"fuzz-afl" => "default",
Revert "Remove heartbeats completely" Done too soon, this is for future OpenSSL 1.2.0 This reverts commit 6c62f9e1639a7d1a879f363a99882920104dfedb. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-15 21:53:33 +08:00
"heartbeats" => "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 23:40:51 +08:00
"md2" => "default",
Add memory sanitizer config, and run on travis. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-29 02:24:28 +08:00
"msan" => "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 23:40:51 +08:00
"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-04 05:45:57 +08:00
"ssl3" => "default",
"ssl3-method" => "default",
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08:00
"ubsan" => "default",
Update Configure to know about tls1_3 Also we disable TLS1.3 by default (use enable-tls1_3 to re-enable). This is because this is a WIP and will not be interoperable with any other TLS1.3 implementation. Finally, we fix some tests that started failing when TLS1.3 was disabled by default. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-30 16:38:52 +08:00
#TODO(TLS1.3): Temporarily disabled while this is a WIP
"tls1_3" => "default",
Make the TLSv1.3 downgrade mechanism a configurable option Make it disabled by default. When TLSv1.3 is out of draft we can remove this option and have it enabled all the time. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3022)
2017-03-22 19:52:45 +08:00
"tls13downgrade" => "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 23:40:51 +08:00
"unit-test" => "default",
"weak-ssl-ciphers" => "default",
"zlib" => "default",
"zlib-dynamic" => "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 20:45:46 +08: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 18:29:51 +08: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 17:03:47 +08: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-19 07:40:54 +08: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 17:03:47 +08: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-24 05:58:51 +08: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 17:03:47 +08:00
sctp requires dgram. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-18 02:17:03 +08: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 18:24:49 +08: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 17:03:47 +08:00
"dtls" => [ @dtls ],
If all versions of a proto are disabled, disabled the proto as well For example, 'no-dtls1 no-dtls1_2' will imply 'no-dtls' Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2670)
2017-02-18 03:48:28 +08:00
sub { 0 == scalar grep { !$disabled{$_} } @dtls }
=> [ "dtls" ],
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 17:03:47 +08:00
# 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}); }
Update Configure to know about tls1_3 Also we disable TLS1.3 by default (use enable-tls1_3 to re-enable). This is because this is a WIP and will not be interoperable with any other TLS1.3 implementation. Finally, we fix some tests that started failing when TLS1.3 was disabled by default. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-30 16:38:52 +08:00
=> [ "tls1", "tls1_1", "tls1_2", "tls1_3",
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 17:03:47 +08:00
"dtls1", "dtls1_2" ],
"tls" => [ @tls ],
If all versions of a proto are disabled, disabled the proto as well For example, 'no-dtls1 no-dtls1_2' will imply 'no-dtls' Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2670)
2017-02-18 03:48:28 +08:00
sub { 0 == scalar grep { !$disabled{$_} } @tls }
=> [ "tls" ],
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 17:03:47 +08:00
Revert "Remove heartbeats completely" Done too soon, this is for future OpenSSL 1.2.0 This reverts commit 6c62f9e1639a7d1a879f363a99882920104dfedb. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-15 21:53:33 +08:00
# 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 19:16:52 +08: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-20 05:08:37 +08: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 09:09:11 +08: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 19:58:15 +08:00
"pic" => [ "shared" ],
"shared" => [ "dynamic-engine" ],
Add new /dev/crypto engine Based on cryptodev-linux Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3744)
2017-03-24 23:19:00 +08:00
"engine" => [ "afalgeng", "devcryptoeng" ],
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 20:44:15 +08:00
# no-autoalginit is only useful when building non-shared
"autoalginit" => [ "shared", "apps" ],
The capi engine uses stdio, so don't build it when configuring 'no-stdio' Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-05 18:54:57 +08:00
"stdio" => [ "apps", "capieng" ],
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 20:44:15 +08:00
"apps" => [ "tests" ],
If 'tests' is disabled, then so should 'external-tests' Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4274)
2017-08-28 21:41:49 +08:00
"tests" => [ "external-tests" ],
Fix compilation with no-ec Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2153)
2016-12-28 23:32:39 +08:00
"comp" => [ "zlib" ],
"ec" => [ "tls1_3" ],
Revert "Remove heartbeats completely" Done too soon, this is for future OpenSSL 1.2.0 This reverts commit 6c62f9e1639a7d1a879f363a99882920104dfedb. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-15 21:53:33 +08:00
sub { !$disabled{"unit-test"} } => [ "heartbeats" ],
Add memory sanitizer config, and run on travis. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-29 02:24:28 +08:00
sub { !$disabled{"msan"} } => [ "asm" ],
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 17:03:47 +08: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 09:21:39 +08: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-11 00:10:39 +08:00
# To remove something from %disabled, use "enable-foo".
Implement Configure option pattern "experimental-foo" (specifically, "experimental-jpake").
2008-12-02 09:21:39 +08:00
# For symmetry, "disable-foo" is a synonym for "no-foo".
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-19 00:19:34 +08:00
my $no_sse2=0;
Certain missing algorithms make some SSL versions or TLS impossible to build.
2001-11-27 19:48:30 +08:00
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
&usage if ($#ARGV < 0);
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 09:17:05 +08: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-19 07:40:54 +08: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 09:33:55 +08: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-12 07:17:12 +08: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-03 02:13:26 +08: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 18:23:45 +08: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 09:33:55 +08: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 17:42:53 +08:00
my %deprecated_options = ();
Add --with-rand-seed Add a new config param to specify how the CSPRNG should be seeded. Illegal values or nonsensical combinations (e.g., anything other than "os" on VMS or HP VOS etc) result in build failures. Add RDSEED support. Add RDTSC but leave it disabled for now pending more investigation. Refactor and reorganization all seeding files (rand_unix/win/vms) so that they are simpler. Only require 128 bits of seeding material. Many document improvements, including why to not use RAND_add() and the limitations around using load_file/write_file. Document RAND_poll(). Cleanup Windows RAND_poll and return correct status More completely initialize the default DRBG. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/3965)
2017-07-18 21:39:21 +08:00
# If you change this, update apps/version.c
my @known_seed_sources = qw(getrandom devrandom os egd none rdcpu librandom);
my @seed_sources = ();
Remove automatic RPATH - add user rpath support Make Configure recognise -rpath and -R to support user added rpaths for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the Unix Makefile, which the users can use as follows: ./config [options] -Wl,-rpath,\$(LIBRPATH) Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 23:05:35 +08:00
while (@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-03 01:54:15 +08:00
{
Remove automatic RPATH - add user rpath support Make Configure recognise -rpath and -R to support user added rpaths for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the Unix Makefile, which the users can use as follows: ./config [options] -Wl,-rpath,\$(LIBRPATH) Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 23:05:35 +08:00
$_ = shift @argvcopy;
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 23:07:05 +08: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 09:33:55 +08: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 18:29:51 +08: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 09:33:55 +08: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 18:29:51 +08:00
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-11 00:10:39 +08:00
if (/^(no|disable|enable)-(.+)$/)
no-ripemd is an alias for no-rmd160 mkdef.pl was failing to understand no-ripemd. This is a deprecated option which should act as an alias for no-rmd160. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-16 18:45:24 +08:00
{
my $word = $2;
if (!exists $deprecated_disablables{$word}
&& !grep { $word =~ /^${_}$/ } @disablables)
{
$unsupported_options{$_} = 1;
next;
}
}
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-11 00:10:39 +08: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-28 06:31:23 +08: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-11 00:10:39 +08: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-20 05:08:37 +08: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 09:06:05 +08: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-20 05:08:37 +08: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 09:06:05 +08: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-20 05:08:37 +08:00
}
no-ripemd is an alias for no-rmd160 mkdef.pl was failing to understand no-ripemd. This is a deprecated option which should act as an alias for no-rmd160. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-16 18:45:24 +08:00
elsif (exists $deprecated_disablables{$1})
{
$deprecated_options{$_} = 1;
if (defined $deprecated_disablables{$1})
{
$disabled{$deprecated_disablables{$1}} = "option";
}
}
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-11 00:10:39 +08: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 23:51:34 +08: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 09:33:55 +08:00
}
Remove "experimental" in code and comments, too. Thanks to Viktor for additional review. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-11 00:10:39 +08: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 09:33:55 +08: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-20 05:08:37 +08: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 09:06:05 +08: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-20 05:08:37 +08: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 09:06:05 +08: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-20 05:08:37 +08: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 17:07:29 +08: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 09:33:55 +08: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 18:29:51 +08: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 23:51:34 +08: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 09:33:55 +08: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-03 02:13:26 +08: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 09:33:55 +08: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-03 02:13:26 +08: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 09:33:55 +08: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-19 07:40:54 +08: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 09:33:55 +08:00
elsif (/^fips$/)
{
Clean up references to FIPS This removes the fips configure option. This option is broken as the required FIPS code is not available. FIPS_mode() and FIPS_mode_set() are retained for compatibility, but FIPS_mode() always returns 0, and FIPS_mode_set() can only be used to turn FIPS mode off. Reviewed-by: Stephen Henson <steve@openssl.org>
2017-02-28 19:30:28 +08:00
die "FIPS mode not supported\n";
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 09:33:55 +08: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$/)
{
Clean up references to FIPS This removes the fips configure option. This option is broken as the required FIPS code is not available. FIPS_mode() and FIPS_mode_set() are retained for compatibility, but FIPS_mode() always returns 0, and FIPS_mode_set() can only be used to turn FIPS mode off. Reviewed-by: Stephen Henson <steve@openssl.org>
2017-02-28 19:30:28 +08:00
die "FIPS mode not supported\n";
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 09:33:55 +08:00
}
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-03 00:36:52 +08: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 09:33:55 +08: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-19 04:35:23 +08: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 09:57:19 +08: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 18:29:51 +08: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 09:33:55 +08:00
elsif (/^--api=(.*)$/)
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-10 00:31:32 +08: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-21 02:03:20 +08: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-10 00:31:32 +08: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 09:33:55 +08: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 23:30:54 +08: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-21 02:03:20 +08: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 23:30:54 +08: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 09:33:55 +08: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 23:30:54 +08: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-19 04:35:23 +08: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 23:30:54 +08: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 09:33:55 +08: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 08:01:09 +08: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-04 00:31:40 +08:00
$withargs{zlib_lib}=$1;
Fix indentation
2011-10-19 17:24:22 +08: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 09:33:55 +08: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 22:35:03 +08: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 22:35:32 +08:00
$withargs{zlib_include}=$1;
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
}
Add support for fuzzing with AFL Reviewed-by: Ben Laurie <ben@links.org> MR: #2740
2016-05-08 04:09:13 +08:00
elsif (/^--with-fuzzer-lib=(.*)$/)
{
$withargs{fuzzer_lib}=$1;
}
elsif (/^--with-fuzzer-include=(.*)$/)
{
$withargs{fuzzer_include}=$1;
}
Add --with-rand-seed Add a new config param to specify how the CSPRNG should be seeded. Illegal values or nonsensical combinations (e.g., anything other than "os" on VMS or HP VOS etc) result in build failures. Add RDSEED support. Add RDTSC but leave it disabled for now pending more investigation. Refactor and reorganization all seeding files (rand_unix/win/vms) so that they are simpler. Only require 128 bits of seeding material. Many document improvements, including why to not use RAND_add() and the limitations around using load_file/write_file. Document RAND_poll(). Cleanup Windows RAND_poll and return correct status More completely initialize the default DRBG. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/3965)
2017-07-18 21:39:21 +08:00
elsif (/^--with-rand-seed=(.*)$/)
{
foreach my $x (split(m|,|, $1))
{
die "Unknown --with-rand-seed choice $x\n"
if ! grep { $x eq $_ } @known_seed_sources;
push @seed_sources, $x;
}
}
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 09:33:55 +08:00
elsif (/^--cross-compile-prefix=(.*)$/)
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-30 05:52:08 +08: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 09:27:30 +08:00
$config{cross_compile_prefix}=$1;
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-30 05:52:08 +08: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 09:33:55 +08:00
elsif (/^--config=(.*)$/)
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 09:33:55 +08: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 18:23:45 +08: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 09:33:55 +08: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 18:29:51 +08: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 09:33:55 +08:00
$libs.=$_." ";
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
}
Configure: recognize -framework as linker option [on Apple OSes]. This is handy for internal iOS tests, when you have to make it work in sandbox. Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-04-04 04:31:05 +08:00
elsif (/^-framework$/)
{
$libs.=$_." ".shift(@argvcopy)." ";
}
Remove automatic RPATH - add user rpath support Make Configure recognise -rpath and -R to support user added rpaths for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the Unix Makefile, which the users can use as follows: ./config [options] -Wl,-rpath,\$(LIBRPATH) Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 23:05:35 +08:00
elsif (/^-rpath$/ or /^-R$/)
# -rpath is the OSF1 rpath flag
# -R is the old Solaris rpath flag
{
my $rpath = shift(@argvcopy) || "";
$rpath .= " " if $rpath ne "";
$libs.=$_." ".$rpath;
}
Configure: recognize -static as link option and disable incompatible options. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-14 23:24:10 +08:00
elsif (/^-static$/)
{
$libs.=$_." ";
Configure: clarify and refine -static. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-09-02 03:36:13 +08:00
$disabled{"dso"} = "forced";
Configure: recognize -static as link option and disable incompatible options. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-14 23:24:10 +08:00
$disabled{"pic"} = "forced";
$disabled{"shared"} = "forced";
$disabled{"threads"} = "forced";
}
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 09:17:05 +08: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 09:33:55 +08: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-13 03:40:33 +08: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 09:33:55 +08: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-11 04:34:48 +08: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 09:33:55 +08: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-12 07:17:12 +08: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 09:33:55 +08: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-12 07:17:12 +08:00
{ $config{options} .= " ".$_; }
Don't confuse mk1mf.pl by combining multiple options into one.
1999-07-09 20:00:34 +08:00
}
Make Configure die when unsupported options are given Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-22 23:33:47 +08: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-21 02:03:20 +08: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 12:00:33 +08: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 17:42:53 +08: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 23:33:47 +08: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 20:00:34 +08:00
}
Certain missing algorithms make some SSL versions or TLS impossible to build.
2001-11-27 19:48:30 +08:00
Allow asan, msan and ubsan to be configured with shared libraries The background story is that util/shlib_wrap.sh was setting LD_PRELOAD or similar platform dependent variables, just in case the shared libraries were built with -rpath. Unfortunately, this doesn't work too well with asan, msan or ubsan. So, the solution is to forbid the combination of shared libraries, -rpath and any of the sanity analyzers we can configure. This changes util/shlib_wrap.sh so it only contains the code that sets LD_PRELOAD when -rpath has been used when configuring. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-08 02:56:20 +08:00
if ($libs =~ /(^|\s)-Wl,-rpath,/
&& !$disabled{shared}
&& !($disabled{asan} && $disabled{msan} && $disabled{ubsan})) {
die "***** Cannot simultaneously use -rpath, shared libraries, and\n",
"***** any of asan, msan or ubsan\n";
}
Add --with-rand-seed Add a new config param to specify how the CSPRNG should be seeded. Illegal values or nonsensical combinations (e.g., anything other than "os" on VMS or HP VOS etc) result in build failures. Add RDSEED support. Add RDTSC but leave it disabled for now pending more investigation. Refactor and reorganization all seeding files (rand_unix/win/vms) so that they are simpler. Only require 128 bits of seeding material. Many document improvements, including why to not use RAND_add() and the limitations around using load_file/write_file. Document RAND_poll(). Cleanup Windows RAND_poll and return correct status More completely initialize the default DRBG. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/3965)
2017-07-18 21:39:21 +08:00
if (scalar(@seed_sources) == 0) {
print "Using implicit seed configuration\n";
push @seed_sources, 'os';
}
die "Cannot seed with none and anything else"
if scalar(grep { $_ eq 'none' } @seed_sources) > 0
&& scalar(@seed_sources) > 1;
push @{$config{openssl_other_defines}},
map { (my $x = $_) =~ tr|[\-a-z]|[_A-Z]|; "OPENSSL_RAND_SEED_$x" }
@seed_sources;
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 17:03:47 +08: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 21:02:57 +08:00
foreach(grep { !defined($disabled{$_}) } @$descendents) {
Fix a few Configure errors Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 17:02:13 +08:00
$new_tocheckfor{$_} = 1; $disabled{$_} = "forced";
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 21:02:57 +08:00
}
Merge from 1.0.0-stable branch.
2009-04-24 00:32:42 +08: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 17:03:47 +08:00
}
@tocheckfor = (keys %new_tocheckfor);
}
Add SRP support.
2011-03-13 01:01:19 +08:00
Have Configure's HASH or TABLE produce complete lists Because some targets execute perl code that might die, we risk incomplete lists. Make it so dying doesn't happen when we're listing targets. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:35 +08:00
our $die = sub { die @_; };
Some assembler-related clean-ups.
1999-05-29 07:18:51 +08:00
if ($target eq "TABLE") {
Have Configure's HASH or TABLE produce complete lists Because some targets execute perl code that might die, we risk incomplete lists. Make it so dying doesn't happen when we're listing targets. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:35 +08:00
local $die = sub { warn @_; };
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 18:53:38 +08:00
foreach (sort keys %table) {
print_table_entry($_, "TABLE");
}
exit 0;
Some assembler-related clean-ups.
1999-05-29 07:18:51 +08:00
}
More compact Configure usage message.
2000-02-21 08:55:45 +08: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 18:53:38 +08:00
foreach (sort keys %table) {
print $_,"\n" unless $table{$_}->{template};
}
exit 0;
More compact Configure usage message.
2000-02-21 08:55:45 +08: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 09:00:21 +08:00
if ($target eq "HASH") {
Have Configure's HASH or TABLE produce complete lists Because some targets execute perl code that might die, we risk incomplete lists. Make it so dying doesn't happen when we're listing targets. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:35 +08:00
local $die = sub { warn @_; };
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 18:53:38 +08: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 09:00:21 +08:00
}
Reorder Configure output "Configuring..." was displayed with './Configure LIST'. This reorders the display of that line to happen after the "targets" LIST, TABLE and HASH have been checked. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3702)
2016-10-03 23:39:11 +08:00
print "Configuring OpenSSL version $config{version} ($config{version_num})\n";
print "for $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 18:53:38 +08:00
# Backward compatibility?
At Corinna Vinschen's request, change CygWin32 to Cygwin
2002-02-14 20:28:24 +08: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 18:53:38 +08:00
$target = "Cygwin".$1;
At Corinna Vinschen's request, change CygWin32 to Cygwin
2002-02-14 20:28:24 +08:00
}
Configure: give config targets the possibility to enable or disable features Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3745)
2017-06-22 06:47:49 +08:00
# Support for legacy targets having a name starting with 'debug-'
my ($d, $t) = $target =~ m/^(debug-)?(.*)$/;
if ($d) {
$config{build_type} = "debug";
# If we do not find debug-foo in the table, the target is set to foo.
if (!$table{$target}) {
$target = $t;
}
}
$config{target} = $target;
my %target = resolve_config($target);
&usage if (!%target || $target{template});
my %conf_files = map { $_ => 1 } (@{$target{_conf_fname_int}});
$config{conf_files} = [ sort keys %conf_files ];
%target = ( %{$table{DEFAULTS}}, %target );
foreach my $feature (@{$target{disable}}) {
if (exists $deprecated_disablables{$feature}) {
warn "***** config $target disables deprecated feature $feature\n";
} elsif (!grep { $feature eq $_ } @disablables) {
die "***** config $target disables unknown feature $feature\n";
}
$disabled{$feature} = 'config';
}
foreach my $feature (@{$target{enable}}) {
if ("default" eq ($disabled{$_} // "")) {
if (exists $deprecated_disablables{$feature}) {
warn "***** config $target enables deprecated feature $feature\n";
} elsif (!grep { $feature eq $_ } @disablables) {
die "***** config $target enables unknown feature $feature\n";
}
delete $disabled{$_};
}
}
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 18:29:51 +08: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-12 07:17:12 +08: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 18:29:51 +08: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 21:12:35 +08: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 18:29:51 +08:00
elsif (/^threads$/)
Clean away $no_threads since we have $disabled{threads} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 21:03:23 +08: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 18:29:51 +08:00
elsif (/^shared$/)
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 20:52:46 +08: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 09:09:11 +08: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 18:29:51 +08:00
elsif (/^zlib$/)
Clean away $zlib since with have $disabled{zlib} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 21:04:45 +08: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 09:06:05 +08:00
elsif (/^dynamic-engine$/)
Update from stable branch.
2005-11-07 01:58:26 +08: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 08:14:29 +08: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 18:29:51 +08: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-21 02:03:20 +08: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-18 02:33:51 +08:00
{
@{$config{dirs}} = grep !/^engines$/, @{$config{dirs}};
@{$config{sdirs}} = grep !/^engine$/, @{$config{sdirs}};
push @{$config{openssl_other_defines}}, "OPENSSL_NO_ENGINE";
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08:00
print " OPENSSL_NO_ENGINE (skip engines)";
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-18 02:33:51 +08: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 18:29:51 +08:00
else
{
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08:00
my ($WHAT, $what);
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 18:29:51 +08:00
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08:00
($WHAT = $what = $_) =~ tr/[\-a-z]/[_A-Z]/;
# Fix up C macro end names
$WHAT = "RMD160" if $what eq "ripemd";
# fix-up crypto/directory name(s)
$what = "ripemd" if $what eq "rmd160";
$what = "whrlpool" if $what eq "whirlpool";
Have the configuration options 'no-err' and 'no-async' work again In an earlier attempt to simplify the processing of disabled options, 'no-err' and 'no-async' stopped working properly. 'err' and 'async' are directories under 'crypto/', but they are special insofar that they can't be simply skipped, like all the algorithm directories can, so they need special treatment among the disablable things. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-09-18 03:57:29 +08:00
if ($what ne "async" && $what ne "err"
&& grep { $_ eq $what } @{$config{sdirs}})
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 18:29:51 +08:00
{
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08:00
push @{$config{openssl_algorithm_defines}}, "OPENSSL_NO_$WHAT";
@{$config{sdirs}} = grep { $_ ne $what} @{$config{sdirs}};
Strip trailing whitespace from Configure.
2014-05-27 00:19:28 +08:00
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08:00
print " OPENSSL_NO_$WHAT (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 18:29:51 +08:00
}
else
{
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08:00
push @{$config{openssl_other_defines}}, "OPENSSL_NO_$WHAT";
print " OPENSSL_NO_$WHAT";
Configure: addendum to OPENSSL_NO_[RMD160|RIPEMD] harmonization. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-01-24 23:46:54 +08:00
Configure: Reorganise the checking of disabled options The way we figured out what options are crypto algorithms and what are something other was somewhat sketchy. This change bases the distinction on available sdirs instead. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07 02:14:33 +08: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 18:29:51 +08:00
}
}
print "\n";
}
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
$target{cxxflags}=$target{cflags} unless defined $target{cxxflags};
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-21 02:03:20 +08: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-16 05:13:41 +08: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-21 02:03:20 +08:00
$target{exe_extension}=".pm" if ($config{target} =~ /vos/);
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08: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-16 00:20:15 +08:00
($target{shared_extension_simple}=$target{shared_extension})
Simplify the handling of shared library version numbers $(SHLIB_MAJOR).$(SHLIB_MINOR) is really a synonym for $(SHLIB_VERSION_NUMBER), and is therefore an added complexity, so better to use $(SHLIB_VERSION_NUMBER) directly. SHLIB_MAJOR and SHLIB_MINOR are now unused, but are kept around purely as information in case someone relies on their existence. At the same time, add support for custom shared library extensions with the three new Makefile variables SHLIB_EXT, SHLIB_EXT_SIMPLE and SHLIB_EXT_IMPORT. By default, they hold the variants of shared library extensions we support. On mingw and cygwin, SHLIB_EXT_IMPORT is defined; on all other Unix platforms, it's empty. An example to get shared libraries with a slightly different SOVER name: $ make SHLIB_EXT='.$(SHLIB_VERSION_NUMBER).so' Fixes #3902 Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3964)
2017-07-19 16:13:41 +08:00
=~ s|\.\$\(SHLIB_VERSION_NUMBER\)||;
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-16 00:20:15 +08:00
$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 09:27:30 +08: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-08 00:41:14 +08: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 19:22:15 +08:00
# Allow overriding the names of some tools. USE WITH CARE
perl: Separate compile-time environment from runtime environment Make it possible to have a separate and different perl command string for installable scripts than we use when building, with the environment variable HASHBANGPERL. Its value default to the same as the environment PERL if it's defined, otherwise '/usr/bin/env perl'. Note: this is only relevant for Unix-like environments. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-07-02 22:39:15 +08:00
# Note: only Unix cares about HASHBANGPERL... that explains
# the default string.
Configure: impose ^X on whole build procedure. Traditionally Configure passed $ENV{PERL} to Makefile. But this resulted in ambiguilty as Configure script could be executed by interpreter different from one executing remaining scripts. Since we separate compile- and run-time interpreters with HASHBANGPERL variable, there is no reason to segment the build procedure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-10 05:45:57 +08:00
$config{perl} = ($^O ne "VMS" ? $^X : "perl");
perl: Separate compile-time environment from runtime environment Make it possible to have a separate and different perl command string for installable scripts than we use when building, with the environment variable HASHBANGPERL. Its value default to the same as the environment PERL if it's defined, otherwise '/usr/bin/env perl'. Note: this is only relevant for Unix-like environments. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-07-02 22:39:15 +08:00
$config{hashbangperl} =
$ENV{'HASHBANGPERL'} || $ENV{'PERL'} || "/usr/bin/env 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 19:22:15 +08:00
$target{cc} = $ENV{'CC'} || $target{cc} || "cc";
Fix C++ support: set $target{cxx} correctly Reviewed-by: Matt Caswell <matt@openssl.org>
2016-10-14 23:44:25 +08:00
$target{cxx} = $ENV{'CXX'} || $target{cxx} || "c++";
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 21:35:55 +08: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-21 03:31:11 +08:00
(which("$config{cross_compile_prefix}ranlib") ?
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 21:35:55 +08: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 19:22:15 +08: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 23:08:13 +08: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 09:00:21 +08:00
Make it possible for the user to specify a different default build file Make sure the information is kept for reconfiguration too. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-30 03:45:19 +08:00
# Allow overriding the build file name
$target{build_file} = $ENV{BUILDFILE} || $target{build_file} || "Makefile";
# Cache information necessary for reconfiguration
Configure: Properly cache the configured compiler command Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-17 21:39:49 +08:00
$config{cc} = $target{cc};
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
$config{cxx} = $target{cxx};
Make it possible for the user to specify a different default build file Make sure the information is kept for reconfiguration too. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-30 03:45:19 +08:00
$config{build_file} = $target{build_file};
Configure: Properly cache the configured compiler command Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-17 21:39:49 +08: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 09:17:05 +08: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 09:00:21 +08: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 17:57:05 +08:00
$config{defines} = [];
$config{cflags} = "";
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
$config{cxxflags} = "";
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 17:57:05 +08:00
$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 08:57:24 +08: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-19 04:35:23 +08: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-30 07:57:33 +08:00
my ($builder, $builder_platform, @builder_opts) =
@{$target{build_scheme}};
Add a platform specific configuration checker For each platform, we may need to perform some basic checks to see that available tools perform as we expect them. For the moment, the added checkers test that Perl gives the expected path format. This should help MingW users to see if they run an appropriate Perl implementation, for example. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2851)
2017-03-06 04:51:18 +08:00
foreach my $checker (($builder_platform."-".$target{build_file}."-checker.pm",
$builder_platform."-checker.pm")) {
my $checker_path = catfile($srcdir, "Configurations", $checker);
if (-f $checker_path) {
my $fn = $ENV{CONFIGURE_CHECKER_WARN}
? sub { warn $@; } : sub { die $@; };
if (! do $checker_path) {
if ($@) {
$fn->($@);
} elsif ($!) {
$fn->($!);
} else {
$fn->("The detected tools didn't match the platform\n");
}
}
last;
}
}
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 22:03:46 +08: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 22:14:45 +08: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-12-01 06:18:02 +08:00
{
Modernise the mingw cflags and ldflags Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-05 22:14:45 +08: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 17:57:05 +08:00
$config{shared_ldflag} .= " -mno-cygwin";
Configure: make -mno-cygwin optional on mingw platforms. PR: 2381
2010-12-01 06:18:02 +08:00
}
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 21:10:45 +08:00
if ($target =~ /linux.*-mips/ && !$disabled{asm} && $user_cflags !~ /-m(ips|arch=)/) {
Configure: add MIPS targets.
2012-09-15 19:21:50 +08: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-21 02:03:20 +08:00
$config{cflags}="-mips2 $config{cflags}" if ($target =~ /mips32/);
$config{cflags}="-mips3 $config{cflags}" if ($target =~ /mips64/);
Configure: add MIPS targets.
2012-09-15 19:21:50 +08: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 19:40:39 +08:00
my $no_shared_warn=0;
./Configure to respect $thread_cflag variable.
2005-01-24 23:58:25 +08: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 09:17:05 +08: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 19:40:39 +08: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 15:09:45 +08: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 21:12:35 +08: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 15:09:45 +08: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-19 04:35:23 +08: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 15:09:45 +08: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 17:57:05 +08: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 15:09:45 +08: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-19 04:35:23 +08: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 15:09:45 +08: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 17:57:05 +08: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 15:09:45 +08: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 17:57:05 +08: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 15:09:45 +08: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-05 06:32:19 +08: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-30 01:07:37 +08:00
$config{ex_libs}="$libs$config{ex_libs}" if ($libs ne "");
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 23:51:34 +08: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-11 04:34:48 +08: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 23:51:34 +08: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 17:11:14 +08: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 12:00:33 +08: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-21 02:03:20 +08: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 12:00:33 +08: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 21:17:26 +08: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-19 04:35:23 +08:00
if ($target{shared_target} eq "")
IA-32 assembler modules (primarily DES) PIC-ification. Idea is to keep shared libraries shared.
2002-12-14 01:56:14 +08: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 09:09:11 +08:00
$no_shared_warn = 1
Clean up references to FIPS This removes the fips configure option. This option is broken as the required FIPS code is not available. FIPS_mode() and FIPS_mode_set() are retained for compatibility, but FIPS_mode() always returns 0, and FIPS_mode_set() can only be used to turn FIPS mode off. Reviewed-by: Stephen Henson <steve@openssl.org>
2017-02-28 19:30:28 +08:00
if (!$disabled{shared} || !$disabled{"dynamic-engine"});
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 20:52:46 +08: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 09:09:11 +08: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-14 01:56:14 +08: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 23:08:53 +08: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 09:06:05 +08: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-20 05:08:37 +08: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 09:06:05 +08: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-20 05:08:37 +08: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-12 02:06:08 +08:00
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08:00
unless ($disabled{asan}) {
$config{cflags} .= "-fsanitize=address ";
}
unless ($disabled{ubsan}) {
Spelling... and more spelling Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1245)
2016-06-20 01:39:01 +08:00
# -DPEDANTIC or -fnosanitize=alignment may also be required on some
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08:00
# platforms.
$config{cflags} .= "-fsanitize=undefined -fno-sanitize-recover=all ";
}
Add memory sanitizer config, and run on travis. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-29 02:24:28 +08:00
unless ($disabled{msan}) {
$config{cflags} .= "-fsanitize=memory ";
}
Configure: complete the changed fuzz option checks Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-06-05 16:59:31 +08:00
unless ($disabled{"fuzz-libfuzzer"} && $disabled{"fuzz-afl"}
Add memory sanitizer config, and run on travis. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-29 02:24:28 +08:00
&& $disabled{asan} && $disabled{ubsan} && $disabled{msan}) {
Add fuzzing! Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-03-27 01:19:14 +08:00
$config{cflags} .= "-fno-omit-frame-pointer -g ";
}
BSD run-time linkers apparently demand RPATH on .so objects. PR: 1381
2007-09-16 20:23:47 +08: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 09:09:11 +08: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-22 03:52:39 +08: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 09:09:11 +08: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-19 04:35:23 +08: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-20 00:06:34 +08: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 09:27:30 +08: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-20 00:06:34 +08:00
}
Clean away $no_asm since with have $disabled{asm} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 21:10:45 +08: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 18:25:33 +08: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-30 02:45:51 +08: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-03 06:41:19 +08: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 08:54:28 +08: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 09:17:05 +08: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 19:00:56 +08: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 09:17:05 +08: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 22:18:06 +08: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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08:00
}
Improve the definition of STITCHED_CALL in e_rc4_hmac_md5.c The definition of STITCHED_CALL relies on OPENSSL_NO_ASM. However, when a configuration simply lacks the assembler implementation for RC4 (which is where we have implemented the stitched call), OPENSSL_NO_ASM isn't implemented. Better, then, to rely on specific macros that indicated that RC4 (and MD5) are implemented in assembler. For this to work properly, we must also make sure Configure adds the definition of RC4_ASM among the C flags. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-08-26 15:59:55 +08:00
if ($target{rc4_asm_src} ne $table{DEFAULTS}->{rc4_asm_src}) {
push @{$config{defines}}, "RC4_ASM";
}
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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08: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 18:25:33 +08: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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08: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-30 02:45:51 +08: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 09:17:05 +08: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-30 02:45:51 +08: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 20:21:52 +08: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 09:17:05 +08: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-30 02:45:51 +08: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 09:17:05 +08: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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08: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-30 02:45:51 +08:00
if ($target{wp_asm_src} =~ /mmx/) {
Configure: restore original logic for -DWHIRLPOOL_ASM. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-29 21:23:24 +08: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 18:25:33 +08: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 21:23:24 +08: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 17:57:05 +08:00
push @{$config{defines}}, "WHIRLPOOL_ASM";
Configure: restore original logic for -DWHIRLPOOL_ASM. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-29 21:23:24 +08: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 08:54:28 +08: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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08: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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08:00
}
Only build the body of e_padlock when there are lower level routines engines/e_padlock.c assumes that for all x86 and x86_64 platforms, the lower level routines will be present. However, that's not always true, for example for solaris-x86-cc, and that leads to build errors. The better solution is to have configure detect if the lower level padlock routines are being built, and define the macro PADLOCK_ASM if they are, and use that macro in our C code. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1510)
2016-08-29 22:58:31 +08:00
if ($target{padlock_asm_src} ne $table{DEFAULTS}->{padlock_asm_src}) {
push @{$config{defines}}, "PADLOCK_ASM";
}
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-30 02:45:51 +08: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 09:17:05 +08: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 08:54:28 +08:00
}
}
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Configure: base compiler-specific decisions on pre-defines. The commit subject is a bit misleading in sense that decisions affect only gcc and gcc-alikes, like clang, recent icc... Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4281)
2017-08-29 21:47:08 +08:00
my %predefined;
if ($^O ne "VMS") {
my $cc = "$config{cross_compile_prefix}$target{cc}";
# collect compiler pre-defines from gcc or gcc-alike...
open(PIPE, "$cc -dM -E -x c /dev/null 2>&1 |");
while (<PIPE>) {
m/^#define\s+(\w+(?:\(\w+\))?)(?:\s+(.+))?/ or last;
$predefined{$1} = $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 23:08:06 +08: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 08:14:29 +08:00
Configure: base compiler-specific decisions on pre-defines. The commit subject is a bit misleading in sense that decisions affect only gcc and gcc-alikes, like clang, recent icc... Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4281)
2017-08-29 21:47:08 +08:00
if (!$disabled{makedepend}) {
# We know that GNU C version 3 and up as well as all clang
# versions support dependency generation
if ($predefined{__GNUC__} >= 3) {
$config{makedepprog} = $cc;
} else {
$config{makedepprog} = which('makedepend');
$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 08:50:28 +08: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-28 02:03:13 +08: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-19 07:40:54 +08: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 08:14:29 +08: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-19 07:40:54 +08: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-24 02:23:25 +08: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-19 07:40:54 +08: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 23:13:21 +08: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-19 07:40:54 +08: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 23:13:21 +08: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-19 07:40:54 +08: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 23:13:21 +08: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-19 07:40:54 +08: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-31 02:06:35 +08: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 17:02:13 +08: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 23:08:53 +08: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-21 02:03:20 +08: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 09:17:05 +08: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 12:00:33 +08:00
}
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-10 00:31:32 +08:00
if ($strict_warnings)
{
my $wopt;
Configure: base compiler-specific decisions on pre-defines. The commit subject is a bit misleading in sense that decisions affect only gcc and gcc-alikes, like clang, recent icc... Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4281)
2017-08-29 21:47:08 +08:00
die "ERROR --strict-warnings requires gcc or gcc-alike"
unless defined($predefined{__GNUC__});
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-10 00:31:32 +08: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-17 06:27:13 +08: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-10 00:31:32 +08:00
}
Configure: base compiler-specific decisions on pre-defines. The commit subject is a bit misleading in sense that decisions affect only gcc and gcc-alikes, like clang, recent icc... Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4281)
2017-08-29 21:47:08 +08:00
if (defined($predefined{__clang__}))
Fix build on MacOS. Reviewed-by: Andy Polyakov
2015-04-19 21:10:54 +08:00
{
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-17 06:27:13 +08:00
$config{cflags} .= " $wopt" unless ($config{cflags} =~ /(?:^|\s)$wopt(?:\s|$)/)
Fix build on MacOS. Reviewed-by: Andy Polyakov
2015-04-19 21:10:54 +08: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 19:16:52 +08: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-03 01:44:26 +08: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-17 06:27:13 +08: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 19:16:52 +08: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-19 04:35:23 +08:00
}
Add new option --strict-warnings to Configure script. This is used to add in devteam warnings into other configurations.
2009-09-10 00:31:32 +08:00
}
Also set the CXXFLAG to the user supplied flags Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2025
2016-12-03 23:57:04 +08:00
if ($user_cflags ne "") { $config{cflags}="$config{cflags}$user_cflags"; $config{cxxflags}="$config{cxxflags}$user_cflags";}
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 20:02:35 +08:00
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 19:21:44 +08: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 16:04:01 +08: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 19:21:44 +08: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 16:04:01 +08: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 18:08:53 +08: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 16:01:01 +08:00
}
Don't check the conditions to build e_afalg if configured "no-engine" Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-09 16:04:01 +08: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 19:21:44 +08: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 21:38:36 +08: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 21:36:47 +08: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 19:21:44 +08: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 21:38:36 +08: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-30 02:45:51 +08: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-10 07:04:04 +08: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-30 07:57:33 +08: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-30 02:45:51 +08:00
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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 17:15:13 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 17:15:13 +08: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 09:00:37 +08: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-30 02:45:51 +08:00
#print STDERR "DEBUG[cleanfile]: $d , $f => $res\n";
return $res;
}
Rearrange the storage of build file template names in %config They are now relative paths as well Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-16 05:55:24 +08:00
# 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.
my @build_file_template_names =
( $builder_platform."-".$target{build_file}.".tmpl",
$target{build_file}.".tmpl" );
my @build_file_templates = ();
# First, look in the user provided directory, if given
if (defined $ENV{$local_config_envname}) {
@build_file_templates =
map {
if ($^O eq 'VMS') {
# VMS environment variables are logical names,
# which can be used as is
$local_config_envname . ':' . $_;
} else {
catfile($ENV{$local_config_envname}, $_);
}
}
@build_file_template_names;
}
# Then, look in our standard directory
push @build_file_templates,
( map { cleanfile($srcdir, catfile("Configurations", $_), $blddir) }
@build_file_template_names );
my $build_file_template;
for $_ (@build_file_templates) {
$build_file_template = $_;
last if -f $build_file_template;
$build_file_template = undef;
}
if (!defined $build_file_template) {
die "*** Couldn't find any of:\n", join("\n", @build_file_templates), "\n";
}
$config{build_file_templates}
= [ $build_file_template,
cleanfile($srcdir, catfile("Configurations", "common.tmpl"),
$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-30 02:45:51 +08:00
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"));
}
Integrate ossl_shim into the build Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-10-12 23:05:06 +08:00
foreach (@{$config{tdirs}}) {
push @build_infos, [ catdir("test", $_), "build.info" ]
if (-f catfile($srcdir, "test", $_, "build.info"));
}
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-30 02:45:51 +08:00
Unified - have configdata.pm depend on a few more things Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-28 08:13:17 +08: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-30 02:45:51 +08: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 23:27:15 +08: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-30 02:45:51 +08:00
my $f = $_->[1];
# The basic things we're trying to build
my @programs = ();
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
my @programs_install = ();
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-30 02:45:51 +08:00
my @libraries = ();
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
my @libraries_install = ();
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-30 02:45:51 +08:00
my @engines = ();
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
my @engines_install = ();
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-30 02:45:51 +08:00
my @scripts = ();
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
my @scripts_install = ();
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-30 02:45:51 +08:00
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 21:50:37 +08: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-30 02:45:51 +08: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 22:45:03 +08: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-30 02:45:51 +08: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 21:37:00 +08: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-30 02:45:51 +08:00
Unified - have configdata.pm depend on a few more things Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-02-28 08:13:17 +08:00
push @{$config{build_infos}}, catfile(abs2rel($sourced, $blddir), $f);
Consolidate the locations where we have our internal perl modules Instead of having perl modules under test/testlib, util and util/perl, consolidate them all to be inside util/perl. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4069)
2017-08-02 04:10:39 +08:00
my $template =
Text::Template->new(TYPE => 'FILE',
SOURCE => catfile($sourced, $f),
PREPEND => qq{use lib "$FindBin::Bin/util/perl";});
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-30 02:45:51 +08:00
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 20:45:46 +08:00
disabled => \%disabled,
Add support for fuzzing with AFL Reviewed-by: Ben Laurie <ben@links.org> MR: #2740
2016-05-08 04:09:13 +08:00
withargs => \%withargs,
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-30 02:45:51 +08: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 21:33:37 +08: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-10 06:58:44 +08: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 21:33:37 +08: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-30 02:45:51 +08: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; },
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
qr/^\s*PROGRAMS(_NO_INST)?\s*=\s*(.*)\s*$/
=> sub {
if (!@skip || $skip[$#skip] > 0) {
my $install = $1;
my @x = tokenize($2);
push @programs, @x;
push @programs_install, @x unless $install;
}
},
qr/^\s*LIBS(_NO_INST)?\s*=\s*(.*)\s*$/
=> sub {
if (!@skip || $skip[$#skip] > 0) {
my $install = $1;
my @x = tokenize($2);
push @libraries, @x;
push @libraries_install, @x unless $install;
}
},
qr/^\s*ENGINES(_NO_INST)?\s*=\s*(.*)\s*$/
=> sub {
if (!@skip || $skip[$#skip] > 0) {
my $install = $1;
my @x = tokenize($2);
push @engines, @x;
push @engines_install, @x unless $install;
}
},
qr/^\s*SCRIPTS(_NO_INST)?\s*=\s*(.*)\s*$/
=> sub {
if (!@skip || $skip[$#skip] > 0) {
my $install = $1;
my @x = tokenize($2);
push @scripts, @x;
push @scripts_install, @x unless $install;
}
},
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-30 02:45:51 +08:00
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 23:39:52 +08: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-30 02:45:51 +08: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 21:50:37 +08: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 23:39:52 +08: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 21:50:37 +08: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-30 02:45:51 +08: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 23:39:52 +08: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-30 02:45:51 +08: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 23:39:52 +08: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-30 02:45:51 +08: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 22:45:03 +08: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 23:39:52 +08: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 22:45:03 +08: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-30 02:45:51 +08: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 23:39:52 +08: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-30 02:45:51 +08:00
if !@skip || $skip[$#skip] > 0 },
Configure: Make it possible to generate mandatory header files 'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be generated before anything else is built. It's likely that a number of source files depend on these header files, this provides a simple way to make sure they are always generated even it the dependency data hasn't been added to the build file yet. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-14 03:57:51 +08:00
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 23:39:52 +08: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-30 02:45:51 +08: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 21:37:00 +08: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-30 02:45:51 +08: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 23:39:52 +08: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-30 02:45:51 +08: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 23:39:52 +08: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-30 02:45:51 +08: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 19:10:27 +08: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-30 02:45:51 +08: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-30 07:57:33 +08: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-30 02:45:51 +08:00
}
},
Allow indented comments in build.info Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
2016-10-25 18:40:32 +08: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-10 07:04:04 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08:00
if ($unified_info{rename}->{$program}) {
$program = $unified_info{rename}->{$program};
}
$unified_info{programs}->{$program} = 1;
}
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
foreach (@programs_install) {
my $program = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$program}) {
$program = $unified_info{rename}->{$program};
}
$unified_info{install}->{programs}->{$program} = 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-30 02:45:51 +08:00
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 09:00:37 +08: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-30 02:45:51 +08:00
if ($unified_info{rename}->{$library}) {
$library = $unified_info{rename}->{$library};
}
$unified_info{libraries}->{$library} = 1;
}
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
foreach (@libraries_install) {
my $library = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$library}) {
$library = $unified_info{rename}->{$library};
}
$unified_info{install}->{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-20 05:08:37 +08: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 09:06:05 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08:00
if ($unified_info{rename}->{$library}) {
$library = $unified_info{rename}->{$library};
}
$unified_info{engines}->{$library} = 1;
}
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
foreach (@engines_install) {
my $library = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$library}) {
$library = $unified_info{rename}->{$library};
}
$unified_info{install}->{engines}->{$library} = 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-30 02:45:51 +08:00
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 09:00:37 +08: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-30 02:45:51 +08:00
if ($unified_info{rename}->{$script}) {
$script = $unified_info{rename}->{$script};
}
$unified_info{scripts}->{$script} = 1;
}
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
foreach (@scripts_install) {
my $script = cleanfile($buildd, $_, $blddir);
if ($unified_info{rename}->{$script}) {
$script = $unified_info{rename}->{$script};
}
$unified_info{install}->{scripts}->{$script} = 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-30 02:45:51 +08:00
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 09:00:37 +08: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-30 02:45:51 +08: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 21:50:37 +08: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-30 02:45:51 +08: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 20:52:46 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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
Make it possible to build static-only libraries The trick is to use the .a extension explicitely in the build.info files. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3243)
2017-04-18 22:24:23 +08:00
# have any, as themselves. Only for libraries that aren't
# explicitely static.
foreach (grep !/\.a$/, keys %{$unified_info{libraries}}) {
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-30 02:45:51 +08:00
if (!defined $unified_info{sharednames}->{$_}) {
$unified_info{sharednames}->{$_} = $_
}
}
Make it possible to build static-only libraries The trick is to use the .a extension explicitely in the build.info files. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3243)
2017-04-18 22:24:23 +08:00
# Check that we haven't defined any library as both shared and
# explicitely static. That is forbidden.
my @doubles = ();
foreach (grep /\.a$/, keys %{$unified_info{libraries}}) {
(my $l = $_) =~ s/\.a$//;
push @doubles, $l if defined $unified_info{sharednames}->{$l};
}
die "these libraries are both explicitely static and shared:\n ",
join(" ", @doubles), "\n"
if @doubles;
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-30 02:45:51 +08:00
}
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 09:00:37 +08: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-30 02:45:51 +08: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 19:42:01 +08: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-30 02:45:51 +08:00
ssl =>
Change names of ordinals and libs, libeay => libcrypto and ssleay => libssl Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-03 19:42:01 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08:00
}
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
# We recognise C++, C and asm files
if ($s =~ /\.(cc|cpp|c|s|S)$/) {
my $o = $_;
$o =~ s/\.[csS]$/.o/; # C and assembler
$o =~ s/\.(cc|cpp)$/_cc.o/; # C++
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 09:00:37 +08: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-30 02:45:51 +08: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 22:45:03 +08: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);
}
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
# We recognise C++, C and asm files
if ($s =~ /\.(cc|cpp|c|s|S)$/) {
my $o = $_;
$o =~ s/\.[csS]$/.o/; # C and assembler
$o =~ s/\.(cc|cpp)$/_cc.o/; # C++
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 22:45:03 +08:00
$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 21:37:00 +08: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-30 02:45:51 +08:00
foreach (keys %depends) {
my $dest = $_;
Configure: Make it possible to generate mandatory header files 'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be generated before anything else is built. It's likely that a number of source files depend on these header files, this provides a simple way to make sure they are always generated even it the dependency data hasn't been added to the build file yet. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-14 03:57:51 +08:00
my $ddest = $dest eq "" ? "" : cleanfile($sourced, $_, $blddir);
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 20:30:08 +08:00
# If the destination doesn't exist in source, it can only be
# a generated file in the build tree.
Configure: Make it possible to generate mandatory header files 'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be generated before anything else is built. It's likely that a number of source files depend on these header files, this provides a simple way to make sure they are always generated even it the dependency data hasn't been added to the build file yet. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-14 03:57:51 +08:00
if ($ddest ne "" && ! -f $ddest) {
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 20:30:08 +08:00
$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-30 02:45:51 +08: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 09:00:37 +08: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-30 02:45:51 +08: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 22:22:27 +08: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 08:29:01 +08:00
|| (grep { $d eq $_ }
map { cleanfile($srcdir, $_, $blddir) }
Configure: Make it possible to generate mandatory header files 'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be generated before anything else is built. It's likely that a number of source files depend on these header files, this provides a simple way to make sure they are always generated even it the dependency data hasn't been added to the build file yet. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-14 03:57:51 +08:00
grep { /\.h$/ } keys %{$unified_info{generate}})) {
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 09:00:37 +08: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-30 02:45:51 +08:00
}
# Take note if the file to depend on is being renamed
Building: make it possible to force linking with static OpenSSL libs Very simply, support having the .a extension to denote depending on static libraries. Note that this is not supported on native Windows when building shared libraries, as there is not static library then, just an import library with the same name. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1889)
2016-11-10 03:01:51 +08:00
# Take extra care with files ending with .a, they should
# be treated without that extension, and the extension
# should be added back after treatment.
$d =~ /(\.a)?$/;
my $e = $1 // "";
$d = $`;
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-30 02:45:51 +08:00
if ($unified_info{rename}->{$d}) {
$d = $unified_info{rename}->{$d};
}
Building: make it possible to force linking with static OpenSSL libs Very simply, support having the .a extension to denote depending on static libraries. Note that this is not supported on native Windows when building shared libraries, as there is not static library then, just an import library with the same name. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1889)
2016-11-10 03:01:51 +08:00
$d .= $e;
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-30 02:45:51 +08:00
$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 20:30:08 +08:00
# If we depend on a header file or a perl module, let's make
# sure it can get included
Configure: Make it possible to generate mandatory header files 'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be generated before anything else is built. It's likely that a number of source files depend on these header files, this provides a simple way to make sure they are always generated even it the dependency data hasn't been added to the build file yet. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-14 03:57:51 +08:00
if ($dest ne "" && $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-30 02:45:51 +08:00
my $i = dirname($d);
Make build.info INCLUDE stmts be both source and build tree relative INCLUDE statements in build.info files were source tree centric. That meant that to get include directory specs in the build tree, we had to resort to perl fragments that specified the build tree include paths as absolute ones. This change has the INCLUDE statement consider both the source and build tree for any include directory. It means that there may be some extra unnecessary include paths, but it also makes life simpler for anyone who makes changes in the build.info files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-30 04:51:42 +08:00
push @{$unified_info{includes}->{$ddest}->{source}}, $i
unless grep { $_ eq $i } @{$unified_info{includes}->{$ddest}->{source}};
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-30 02:45:51 +08:00
}
}
}
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 20:30:08 +08: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-30 02:45:51 +08:00
}
foreach (@{$includes{$dest}}) {
Make build.info INCLUDE stmts be both source and build tree relative INCLUDE statements in build.info files were source tree centric. That meant that to get include directory specs in the build tree, we had to resort to perl fragments that specified the build tree include paths as absolute ones. This change has the INCLUDE statement consider both the source and build tree for any include directory. It means that there may be some extra unnecessary include paths, but it also makes life simpler for anyone who makes changes in the build.info files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-30 04:51:42 +08:00
my $is = cleandir($sourced, $_, $blddir);
my $ib = cleandir($buildd, $_, $blddir);
push @{$unified_info{includes}->{$ddest}->{source}}, $is
unless grep { $_ eq $is } @{$unified_info{includes}->{$ddest}->{source}};
push @{$unified_info{includes}->{$ddest}->{build}}, $ib
unless grep { $_ eq $ib } @{$unified_info{includes}->{$ddest}->{build}};
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-30 02:45:51 +08:00
}
}
}
### 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 21:50:37 +08: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-30 02:45:51 +08:00
$unified_info{$_} = [ sort keys %{$unified_info{$_}} ];
}
# Two level structures
build.info: implement PROGRAM_NO_INST, and dito for ENGINES, SCRIPTS, LIBS PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are to be used to specify program, engines, scripts and libraries that are not to be installed in the system. Fuzzers, test programs, that sort of things are of the _NO_INST type, for example. For the benefit of build file templates and other templates that use data from configdata.pm, a new hash table $unified_info{install} is created. It contains a set of subhashes, one for each type of installable, each having an array of file names as values. For example, it can look like this: "install" => { "engines" => [ "engines/afalg/afalg", "engines/capi", "engines/dasync", "engines/padlock", ], "libraries" => [ "libcrypto", "libssl", ], "programs" => [ "apps/openssl", ], "scripts" => [ "apps/CA.pl", "apps/tsget", "tools/c_rehash", ], }, Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-08 20:28:58 +08:00
foreach my $l1 (("install", "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-30 02:45:51 +08:00
foreach my $l2 (sort keys %{$unified_info{$l1}}) {
$unified_info{$l1}->{$l2} =
[ sort keys %{$unified_info{$l1}->{$l2}} ];
}
}
Make build.info INCLUDE stmts be both source and build tree relative INCLUDE statements in build.info files were source tree centric. That meant that to get include directory specs in the build tree, we had to resort to perl fragments that specified the build tree include paths as absolute ones. This change has the INCLUDE statement consider both the source and build tree for any include directory. It means that there may be some extra unnecessary include paths, but it also makes life simpler for anyone who makes changes in the build.info files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-30 04:51:42 +08:00
# Includes
foreach my $dest (sort keys %{$unified_info{includes}}) {
if (defined($unified_info{includes}->{$dest}->{build})) {
my @source_includes =
( @{$unified_info{includes}->{$dest}->{source}} );
$unified_info{includes}->{$dest} =
[ @{$unified_info{includes}->{$dest}->{build}} ];
foreach my $inc (@source_includes) {
push @{$unified_info{includes}->{$dest}}, $inc
unless grep { $_ eq $inc } @{$unified_info{includes}->{$dest}};
}
} else {
$unified_info{includes}->{$dest} =
[ @{$unified_info{includes}->{$dest}->{source}} ];
}
}
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-30 02:45:51 +08:00
}
# 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-19 01:43:56 +08: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-30 02:45:51 +08: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-19 01:43:56 +08:00
(my $obj = $_) =~ s/_(asm|aux)_src$/_obj/;
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
$target{$obj} = $target{$src};
$target{$obj} =~ s/\.[csS]\b/.o/g; # C and assembler
$target{$obj} =~ s/\.(cc|cpp)\b/_cc.o/g; # C++
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-30 02:45:51 +08: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-19 04:35:23 +08: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-19 07:41:14 +08: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-19 04:35:23 +08: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 09:09:33 +08: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-19 07:41:14 +08: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 09:09:33 +08: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-19 04:35:23 +08: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-21 02:03:20 +08: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-24 07:35:30 +08: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-21 02:03:20 +08: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-30 07:57:33 +08: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-30 02:45:51 +08: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 18:52:47 +08:00
close(OUT);
Make Configure work again after eliminating files.
1998-12-29 06:05:44 +08:00
Trim config output With extensive help and feedback from Richard and Andy. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-07 00:26:38 +08:00
print "\n";
print "PROCESSOR =$config{processor}\n" if $config{processor};
print "PERL =$config{perl}\n";
Configure: impose ^X on whole build procedure. Traditionally Configure passed $ENV{PERL} to Makefile. But this resulted in ambiguilty as Configure script could be executed by interpreter different from one executing remaining scripts. Since we separate compile- and run-time interpreters with HASHBANGPERL variable, there is no reason to segment the build procedure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-10 05:45:57 +08:00
print "PERLVERSION =$Config{version} for $Config{archname}\n";
Trim config output With extensive help and feedback from Richard and Andy. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-07 00:26:38 +08:00
print "HASHBANGPERL =$config{hashbangperl}\n";
Configure: adhere to $(CROSS_COMPILE)ranlib. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-09 21:35:55 +08: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 17:57:05 +08:00
print "CFLAG =$target{cflags} $config{cflags}\n";
Add support for C++ in Configure A note: this will form object file names by changing '.cc' to '_cc.o'. This will permit other configuration code to recognise these object files were built for C++ rather than C. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-12 21:30:08 +08:00
print "CXX =$config{cross_compile_prefix}$target{cxx}\n"
if defined $target{cxx};
print "CXXFLAG =$target{cxxflags} $config{cxxflags}\n"
if defined $target{cxx};
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 17:57:05 +08:00
print "DEFINES =",join(" ", @{$target{defines}}, @{$config{defines}}),"\n";
Trim config output With extensive help and feedback from Richard and Andy. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-07 00:26:38 +08:00
#print "RANLIB =", $target{ranlib} eq '$(CROSS_COMPILE)ranlib' ?
# "$config{cross_compile_prefix}ranlib" :
# "$target{ranlib}", "\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 17:57:05 +08:00
print "EX_LIBS =$target{ex_libs} $config{ex_libs}\n";
Always make links.
1999-03-07 22:05:36 +08: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 20:31:49 +08: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-30 02:45:51 +08: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-30 07:57:33 +08:00
run_dofile(catfile($blddir, $target{build_file}),
Rearrange the storage of build file template names in %config They are now relative paths as well Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-16 05:55:24 +08:00
@{$config{build_file_templates}});
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-30 02:45:51 +08: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 20:31:49 +08: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-30 07:57:33 +08:00
$builders{$builder}->($builder_platform, @builder_opts);
Strip trailing whitespace from Configure.
2014-05-27 00:19:28 +08: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 23:51:34 +08: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-30 00:10:09 +08: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-27 05:25:01 +08: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-24 06:13:45 +08: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 08:46:21 +08: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 19:40:39 +08: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 09:09:11 +08: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-11 01:31:01 +08: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-22 00:03:16 +08: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 18:52:47 +08: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 08:57:24 +08: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 16:09:31 +08: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 08:57:24 +08: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 21:10:45 +08: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 08:57:24 +08: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 21:10:45 +08: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 08:57:24 +08:00
}
}
Make picker, thread and combine standard config helper functions Document them as well Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-17 16:09:31 +08: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 23:51:34 +08: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 20:31:49 +08: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 09:17:05 +08: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 20:31:49 +08: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 18:08:21 +08: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 20:31:49 +08: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 18:08:21 +08: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 20:31:49 +08: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 23:51:34 +08: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 20:31:49 +08: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 18:08:21 +08: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 20:31:49 +08: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-25 07:17:59 +08: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 20:31:49 +08: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-25 07:17:59 +08: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 20:31:49 +08: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 08:57:24 +08: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 = ();
{
Register the name of the config file each config target was found in Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-15 04:21:41 +08:00
# Protect certain tables from tampering
local %table = %::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 08:57:24 +08:00
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{$_};
Register the name of the config file each config target was found in Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-15 04:21:41 +08:00
} else {
$targets{$_}->{_conf_fname_int} = add([ $fname ]);
}
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 08:57:24 +08:00
}
%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-11 04:34:48 +08: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 08:57:24 +08: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-10 00:18:07 +08: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 23:51:34 +08: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 08:57:24 +08: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 21:02:57 +08: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 08:57:24 +08: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 21:02:57 +08: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 08:57:24 +08: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-11 04:34:48 +08: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 08:57:24 +08: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 19:25:13 +08: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 08:57:24 +08: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 18:08:21 +08: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 23:51:34 +08: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 18:08:21 +08: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 23:51:34 +08: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 18:08:21 +08: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 08:57:24 +08: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 23:51:34 +08: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 08:57:24 +08: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 18:08:21 +08: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-10 00:18:07 +08: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 08:57:24 +08:00
}
# Finally done, return the result.
return %{$table{$target}};
}
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
sub usage
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
{
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
print STDERR $usage;
More compact Configure usage message.
2000-02-21 08:55:45 +08:00
print STDERR "\npick os/compiler from:\n";
Add strictness, fix variable substition bugs.
1998-12-29 01:08:48 +08:00
my $j=0;
Minor tweaks to keep Perl 5.001 happy.
1999-02-08 02:22:15 +08:00
my $i;
More compact Configure usage message.
2000-02-21 08:55:45 +08:00
my $k=0;
Minor tweaks to keep Perl 5.001 happy.
1999-02-08 02:22:15 +08:00
foreach $i (sort keys %table)
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08: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 08:57:24 +08:00
next if $table{$i}->{template};
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
next if $i =~ /^debug/;
More compact Configure usage message.
2000-02-21 08:55:45 +08: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-25 06:59:36 +08: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 08:57:24 +08:00
next if $table{$i}->{template};
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
next if $i !~ /^debug/;
More compact Configure usage message.
2000-02-21 08:55:45 +08: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 18:52:47 +08:00
}
More compact Configure usage message.
2000-02-21 08:55:45 +08: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-25 06:59:36 +08:00
exit(1);
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
}
Fix a few Configure errors Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-14 17:02:13 +08: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-21 02:03:20 +08: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-30 02:45:51 +08: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-21 02:03:20 +08:00
Templatize util/domd Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-01-30 02:29:45 +08: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-30 02:45:51 +08:00
foreach (@templates) {
die "Can't open $_, $!" unless -f $_;
}
The Perl interpreter might be in a path with spaces, so maybe quote it Note: some shells do not like the command verb to be quoted, so we avoid it unless it's actually necessary. RT#4665 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-31 00:41:00 +08:00
my $perlcmd = (quotify("maybeshell", $config{perl}))[0];
my $cmd = "$perlcmd \"-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-30 02:45:51 +08: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-21 02:03:20 +08: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-21 03:31:11 +08: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 18:53:38 +08: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-26 04:51:22 +08: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 18:53:38 +08: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 09:17:05 +08: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-26 04:51:22 +08: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 18:53:38 +08:00
"lflags",
Configure's print_table_entry printed incorrect information Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:08 +08:00
"loutflag",
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 18:47:14 +08: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-30 01:07:37 +08: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 18:53:38 +08:00
"bn_ops",
Configure's print_table_entry printed incorrect information Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:08 +08:00
"apps_aux_src",
"cpuid_asm_src",
"uplink_aux_src",
"bn_asm_src",
"ec_asm_src",
"des_asm_src",
"aes_asm_src",
"bf_asm_src",
"md5_asm_src",
"cast_asm_src",
"sha1_asm_src",
"rc4_asm_src",
"rmd160_asm_src",
"rc5_asm_src",
"wp_asm_src",
"cmll_asm_src",
"modes_asm_src",
"padlock_asm_src",
"chacha_asm_src",
"poly1035_asm_src",
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 23:51:34 +08: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 18:53:38 +08:00
"perlasm_scheme",
"dso_scheme",
"shared_target",
"shared_cflag",
Configure's print_table_entry printed incorrect information Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:08 +08:00
"shared_defines",
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 18:53:38 +08:00
"shared_ldflag",
Add support for shared_rcflag, useful for windres (Cygwin and Mingw) Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-05 22:17:33 +08: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 18:53:38 +08: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-16 00:20:15 +08:00
"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-26 04:51:22 +08: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 18:53:38 +08: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-26 04:51:22 +08: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 18:53:38 +08:00
"arflags",
Configure's print_table_entry printed incorrect information Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-01 01:47:08 +08:00
"aroutflag",
"rc",
"rcflags",
"rcoutflag",
"mt",
"mtflags",
"mtinflag",
"mtoutflag",
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 18:53:38 +08:00
"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-26 04:51:22 +08: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 18:53:38 +08: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 08:32:51 +08: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 18:53:38 +08: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 08:32:51 +08: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 18:53:38 +08: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 09:00:37 +08: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";
More typo fixes Fix some comments too [skip ci] Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3069)
2017-03-29 05:57:28 +08:00
# If the file spec includes a device or a directory spec,
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 09:00:37 +08:00
# 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 17:15:13 +08: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 09:33:55 +08:00
sub quotify {
my %processors = (
perl => sub { my $x = shift;
$x =~ s/([\\\$\@"])/\\$1/g;
return '"'.$x.'"'; },
The Perl interpreter might be in a path with spaces, so maybe quote it Note: some shells do not like the command verb to be quoted, so we avoid it unless it's actually necessary. RT#4665 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-31 00:41:00 +08:00
maybeshell => sub { my $x = shift;
(my $y = $x) =~ s/([\\\"])/\\$1/g;
if ($x ne $y || $x =~ m|\s|) {
return '"'.$y.'"';
} else {
return $x;
}
},
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 09:33:55 +08:00
);
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 21:02:57 +08: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 09:33:55 +08: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-21 02:03:20 +08: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-30 02:45:51 +08: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 19:10:27 +08: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-30 02:45:51 +08: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 19:10:27 +08: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-30 02:45:51 +08: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-21 02:03:20 +08: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-30 02:45:51 +08: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-21 02:03:20 +08: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-30 02:45:51 +08: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 19:10:27 +08: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-30 02:45:51 +08: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-10 07:04:04 +08: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-30 02:45:51 +08: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-10 07:04:04 +08: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-30 02:45:51 +08: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-10 07:04:04 +08: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-21 02:03:20 +08: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 23:39:52 +08: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 New Issue Copy Permalink