wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
openssl/apps/build.info

43 lines
1.6 KiB
Text
Raw Normal View History

Make sure the 'tsget' script is called 'tsget.pl' everywhere The result is that we don't have to produce different names on different platforms, and we won't have confusion on Windows depending on if the script was built with mingw or with MSVC. Partial fix for #3254 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6764)
2018-07-23 11:25:45 +00:00
{- our @apps_openssl_src =
Apps: divide the modules in direct command modules, support library and init Most modules are direct implementations of openssl application sub-commands, but some constitute a support library, which can be used by more than one program (and is, incidently, by test/uitest). For practical purposes, we place the support library modules in a private, static library. Finally, there are some modules that don't have direct references in the rest of the apps code, but are still crucial. See them as some kind of extra crt0 or similar for your platform. Inspiration from David von Oheimb Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5222)
2018-01-31 13:15:52 +00:00
qw(openssl.c
asn1pars.c ca.c ciphers.c cms.c crl.c crl2p7.c dgst.c dhparam.c
dsa.c dsaparam.c ec.c ecparam.c enc.c engine.c errstr.c gendsa.c
genpkey.c genrsa.c nseq.c ocsp.c passwd.c pkcs12.c pkcs7.c pkcs8.c
pkey.c pkeyparam.c pkeyutl.c prime.c rand.c req.c rsa.c rsautl.c
s_client.c s_server.c s_time.c sess_id.c smime.c speed.c spkac.c
srp.c ts.c verify.c version.c x509.c rehash.c storeutl.c);
our @apps_lib_src =
Updated test command line parsing to support commmon commands Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6975)
2018-08-16 02:36:01 +00:00
( qw(apps.c apps_ui.c opt.c fmt.c s_cb.c s_socket.c app_rand.c
bf_prefix.c),
Apps: divide the modules in direct command modules, support library and init Most modules are direct implementations of openssl application sub-commands, but some constitute a support library, which can be used by more than one program (and is, incidently, by test/uitest). For practical purposes, we place the support library modules in a private, static library. Finally, there are some modules that don't have direct references in the rest of the apps code, but are still crucial. See them as some kind of extra crt0 or similar for your platform. Inspiration from David von Oheimb Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5222)
2018-01-31 13:15:52 +00:00
split(/\s+/, $target{apps_aux_src}) );
our @apps_init_src = split(/\s+/, $target{apps_init_src});
Make sure tsget and c_rehash are named with .pl suffix on Windows and VMS Especially on Windows, the .pl suffix is associated with the perl interpreter, and therefore make those scripts usable as commands of their own. On VMS, it simply looks better. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-05-23 13:49:25 +00:00
"" -}
Fix no-stdio and no-autoalginit no-stdio does not work with the apps. Since the tests also need the apps it doesn't support that either. Therefore we disable building of both. no-autoalginit is not compatible with the apps because it requires explicit loading of the algorithms, and the apps don't do that. Therefore we disable building the apps for this option. Similarly the tests depend on the apps so we also disable the tests. Finally the whole point about no-autoalginit is to avoid excessive executable sizes when doing static linking. Therefore we disable "shared" if this option is selected. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-14 12:44:15 +00:00
IF[{- !$disabled{apps} -}]
Build: Change all _NO_INST to use attributes instead. This means that all PROGRAMS_NO_INST, LIBS_NO_INST, ENGINES_NO_INST and SCRIPTS_NO_INST are changed to be PROGRAM, LIBS, ENGINES and SCRIPTS with the associated attribute 'noinst'. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7581)
2018-11-07 10:02:06 +00:00
LIBS{noinst}=libapps.a
Apps: divide the modules in direct command modules, support library and init Most modules are direct implementations of openssl application sub-commands, but some constitute a support library, which can be used by more than one program (and is, incidently, by test/uitest). For practical purposes, we place the support library modules in a private, static library. Finally, there are some modules that don't have direct references in the rest of the apps code, but are still crucial. See them as some kind of extra crt0 or similar for your platform. Inspiration from David von Oheimb Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5222)
2018-01-31 13:15:52 +00:00
SOURCE[libapps.a]={- join(" ", @apps_lib_src) -}
Move libapps headers into their own directory This got triggered by test/testutil.h including ../apps/opt.h. Some compilers do all inclusions from the directory of the C file being compiled, so when a C file includes a header file with a relative file spec, and that header file also includes another header file with a relative file spec, the compiler no longer follows. As a specific example, test/testutil/basic_output.c included ../testutil.h. Fine so far, but then, test/testutil.h includes ../apps/opt.h, and the compiler ends up trying to include (seen from the source top) test/apps/opt.h rather than apps/opt.h, and fails. The solution could have been to simply add apps/ as an inclusion directory. However, that directory also has header files that have nothing to do with libapps, so we take this a bit further, create apps/include and move libapps specific headers there, and then add apps/include as inclusion directory in the build.info files where needed. Reviewed-by: Paul Yang <yang.yang@baishancloud.com> (Merged from https://github.com/openssl/openssl/pull/8210)
2019-02-12 10:37:43 +00:00
INCLUDE[libapps.a]=.. ../include include
Apps: divide the modules in direct command modules, support library and init Most modules are direct implementations of openssl application sub-commands, but some constitute a support library, which can be used by more than one program (and is, incidently, by test/uitest). For practical purposes, we place the support library modules in a private, static library. Finally, there are some modules that don't have direct references in the rest of the apps code, but are still crucial. See them as some kind of extra crt0 or similar for your platform. Inspiration from David von Oheimb Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5222)
2018-01-31 13:15:52 +00:00
Fix no-stdio and no-autoalginit no-stdio does not work with the apps. Since the tests also need the apps it doesn't support that either. Therefore we disable building of both. no-autoalginit is not compatible with the apps because it requires explicit loading of the algorithms, and the apps don't do that. Therefore we disable building the apps for this option. Similarly the tests depend on the apps so we also disable the tests. Finally the whole point about no-autoalginit is to avoid excessive executable sizes when doing static linking. Therefore we disable "shared" if this option is selected. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-14 12:44:15 +00:00
PROGRAMS=openssl
Apps: divide the modules in direct command modules, support library and init Most modules are direct implementations of openssl application sub-commands, but some constitute a support library, which can be used by more than one program (and is, incidently, by test/uitest). For practical purposes, we place the support library modules in a private, static library. Finally, there are some modules that don't have direct references in the rest of the apps code, but are still crucial. See them as some kind of extra crt0 or similar for your platform. Inspiration from David von Oheimb Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5222)
2018-01-31 13:15:52 +00:00
SOURCE[openssl]={- join(" ", @apps_init_src) -}
Build apps/progs.h dynamically Because apps/progs.h isn't configuration agnostic, it's not at all suited for 'make update' or being versioned, so change it to be dynamically generated. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3688)
2017-06-15 17:31:01 +00:00
SOURCE[openssl]={- join(" ", @apps_openssl_src) -}
Move libapps headers into their own directory This got triggered by test/testutil.h including ../apps/opt.h. Some compilers do all inclusions from the directory of the C file being compiled, so when a C file includes a header file with a relative file spec, and that header file also includes another header file with a relative file spec, the compiler no longer follows. As a specific example, test/testutil/basic_output.c included ../testutil.h. Fine so far, but then, test/testutil.h includes ../apps/opt.h, and the compiler ends up trying to include (seen from the source top) test/apps/opt.h rather than apps/opt.h, and fails. The solution could have been to simply add apps/ as an inclusion directory. However, that directory also has header files that have nothing to do with libapps, so we take this a bit further, create apps/include and move libapps specific headers there, and then add apps/include as inclusion directory in the build.info files where needed. Reviewed-by: Paul Yang <yang.yang@baishancloud.com> (Merged from https://github.com/openssl/openssl/pull/8210)
2019-02-12 10:37:43 +00:00
INCLUDE[openssl]=.. ../include include
Apps: divide the modules in direct command modules, support library and init Most modules are direct implementations of openssl application sub-commands, but some constitute a support library, which can be used by more than one program (and is, incidently, by test/uitest). For practical purposes, we place the support library modules in a private, static library. Finally, there are some modules that don't have direct references in the rest of the apps code, but are still crucial. See them as some kind of extra crt0 or similar for your platform. Inspiration from David von Oheimb Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5222)
2018-01-31 13:15:52 +00:00
DEPEND[openssl]=libapps.a ../libssl
unified build scheme: add build.info files Now that we have the foundation for the "unified" build scheme in place, we add build.info files. They have been generated from the Makefiles in the same directories. Things that are platform specific will appear in later commits. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-01-29 22:33:10 +00:00
Fix resource files Add it to apps as well as libraries. Fix the copyright year generation. Thanks to user RTT for pointing this out. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5704)
2018-03-22 14:21:33 +00:00
IF[{- $config{target} =~ /^(?:Cygwin|mingw|VC-)/ -}]
GENERATE[openssl.rc]=../util/mkrc.pl openssl
SOURCE[openssl]=openssl.rc
ENDIF
Build apps/progs.h dynamically Because apps/progs.h isn't configuration agnostic, it's not at all suited for 'make update' or being versioned, so change it to be dynamically generated. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3688)
2017-06-15 17:31:01 +00:00
{- join("\n ", map { (my $x = $_) =~ s|\.c$|.o|; "DEPEND[$x]=progs.h" }
@apps_openssl_src) -}
GENERATE[progs.h]=progs.pl $(APPS_OPENSSL)
DEPEND[progs.h]=../configdata.pm
Build: use attributes to indicate installed script classes We have two classes of scripts to be installed, those that are installed as "normal" programs, and those that are installed as "misc" scripts. These classes are installed in different locations, so the build file templates must pay attention. Because we didn't have the tools to indicate what scripts go where, we had these scripts hard coded in the build template files, with the maintenance issues that may cause. Now that we have attributes, those can be used to classify the installed scripts, and have the build file templates simply check the attributes to know what's what. Furthermore, the 'tsget.pl' script exists both as 'tsget.pl' and 'tsget', which is done by installing a symbolic link (or copy). This link name is now given through an attribute, which results in even less hard coding in the Unix Makefile template. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7581)
2018-11-07 10:05:17 +00:00
SCRIPTS{misc}=CA.pl
Fix no-stdio and no-autoalginit no-stdio does not work with the apps. Since the tests also need the apps it doesn't support that either. Therefore we disable building of both. no-autoalginit is not compatible with the apps because it requires explicit loading of the algorithms, and the apps don't do that. Therefore we disable building the apps for this option. Similarly the tests depend on the apps so we also disable the tests. Finally the whole point about no-autoalginit is to avoid excessive executable sizes when doing static linking. Therefore we disable "shared" if this option is selected. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-14 12:44:15 +00:00
SOURCE[CA.pl]=CA.pl.in
Build: use attributes to indicate installed script classes We have two classes of scripts to be installed, those that are installed as "normal" programs, and those that are installed as "misc" scripts. These classes are installed in different locations, so the build file templates must pay attention. Because we didn't have the tools to indicate what scripts go where, we had these scripts hard coded in the build template files, with the maintenance issues that may cause. Now that we have attributes, those can be used to classify the installed scripts, and have the build file templates simply check the attributes to know what's what. Furthermore, the 'tsget.pl' script exists both as 'tsget.pl' and 'tsget', which is done by installing a symbolic link (or copy). This link name is now given through an attribute, which results in even less hard coding in the Unix Makefile template. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7581)
2018-11-07 10:05:17 +00:00
# linkname tells build files that a symbolic link or copy of this script
# without extension must be installed as well. Unix or Unix lookalike only.
SCRIPTS{misc,linkname=tsget}=tsget.pl
Make sure the 'tsget' script is called 'tsget.pl' everywhere The result is that we don't have to produce different names on different platforms, and we won't have confusion on Windows depending on if the script was built with mingw or with MSVC. Partial fix for #3254 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6764)
2018-07-23 11:25:45 +00:00
SOURCE[tsget.pl]=tsget.in
Fix no-stdio and no-autoalginit no-stdio does not work with the apps. Since the tests also need the apps it doesn't support that either. Therefore we disable building of both. no-autoalginit is not compatible with the apps because it requires explicit loading of the algorithms, and the apps don't do that. Therefore we disable building the apps for this option. Similarly the tests depend on the apps so we also disable the tests. Finally the whole point about no-autoalginit is to avoid excessive executable sizes when doing static linking. Therefore we disable "shared" if this option is selected. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-14 12:44:15 +00:00
ENDIF
Reference in a new issue Copy permalink