2019-06-16 18:56:21 +08:00
|
|
|
# Program init source, that don't have direct linkage with the rest of the
|
|
|
|
# source, and can therefore not be part of a library.
|
|
|
|
IF[{- !$disabled{uplink} -}]
|
|
|
|
$INITSRC=../ms/applink.c
|
|
|
|
ENDIF
|
|
|
|
IF[{- $config{target} =~ /^vms-/ -}]
|
|
|
|
$INITSRC=vms_decc_init.c
|
|
|
|
ENDIF
|
|
|
|
|
|
|
|
# Auxilliary program source
|
|
|
|
IF[{- $config{target} =~ /^(?:VC-|mingw)/ -}]
|
|
|
|
# It's called 'init', but doesn't have much 'init' in it...
|
|
|
|
$AUXLIBAPPSSRC=win32_init.c
|
|
|
|
ENDIF
|
|
|
|
IF[{- $config{target} =~ /^vms-/ -}]
|
|
|
|
$AUXLIBAPPSSRC=vms_term_sock.c vms_decc_argv.c
|
|
|
|
ENDIF
|
|
|
|
|
|
|
|
# Source for the 'openssl' program
|
|
|
|
# We need the perl variable for the DEPEND generator further down.
|
|
|
|
$OPENSSLSRC={-
|
|
|
|
our @opensslsrc =
|
2019-07-11 02:19:36 +08:00
|
|
|
qw(openssl.c progs.c
|
2018-01-31 21:15:52 +08:00
|
|
|
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
|
2019-04-16 18:10:04 +08:00
|
|
|
genpkey.c genrsa.c kdf.c mac.c nseq.c ocsp.c passwd.c pkcs12.c pkcs7.c
|
2018-11-20 08:45:44 +08:00
|
|
|
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
|
2019-04-09 20:39:54 +08:00
|
|
|
spkac.c srp.c ts.c verify.c version.c x509.c rehash.c storeutl.c
|
2019-08-27 04:09:27 +08:00
|
|
|
list.c info.c provider.c fipsinstall.c);
|
2019-06-16 18:56:21 +08:00
|
|
|
join(' ', @opensslsrc); -}
|
|
|
|
# Source for libapps
|
|
|
|
$LIBAPPSSRC=apps.c apps_ui.c opt.c fmt.c s_cb.c s_socket.c app_rand.c \
|
2019-08-27 04:08:04 +08:00
|
|
|
bf_prefix.c columns.c lib/app_params.c
|
2019-06-16 18:56:21 +08:00
|
|
|
|
2016-04-14 20:44:15 +08:00
|
|
|
IF[{- !$disabled{apps} -}]
|
2018-11-07 18:02:06 +08:00
|
|
|
LIBS{noinst}=libapps.a
|
2019-06-16 18:56:21 +08:00
|
|
|
SOURCE[libapps.a]=$LIBAPPSSRC $AUXLIBAPPSSRC
|
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 18:37:43 +08:00
|
|
|
INCLUDE[libapps.a]=.. ../include include
|
2018-01-31 21:15:52 +08:00
|
|
|
|
2016-04-14 20:44:15 +08:00
|
|
|
PROGRAMS=openssl
|
2019-06-16 18:56:21 +08:00
|
|
|
SOURCE[openssl]=$INITSRC $OPENSSLSRC
|
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 18:37:43 +08:00
|
|
|
INCLUDE[openssl]=.. ../include include
|
2018-01-31 21:15:52 +08:00
|
|
|
DEPEND[openssl]=libapps.a ../libssl
|
2016-01-30 06:33:10 +08:00
|
|
|
|
2019-06-16 18:56:21 +08:00
|
|
|
IF[{- $config{target} =~ /^(?:Cygwin|mingw|VC-)/ -}]
|
|
|
|
GENERATE[openssl.rc]=../util/mkrc.pl openssl
|
|
|
|
SOURCE[openssl]=openssl.rc
|
|
|
|
ENDIF
|
2018-03-22 22:21:33 +08:00
|
|
|
|
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 18:05:17 +08:00
|
|
|
SCRIPTS{misc}=CA.pl
|
2016-04-14 20:44:15 +08: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 18:05:17 +08: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
|
2018-07-23 19:25:45 +08:00
|
|
|
SOURCE[tsget.pl]=tsget.in
|
2016-04-14 20:44:15 +08:00
|
|
|
ENDIF
|