2017-12-01 14:29:05 +00:00
|
|
|
my %targets = (
|
2016-05-01 12:33:19 +00:00
|
|
|
"haiku-common" => {
|
|
|
|
|
template => 1,
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CC => "cc",
|
|
|
|
|
CFLAGS => add_before(picker(default => "-Wall",
|
2016-05-01 12:33:19 +00:00
|
|
|
debug => "-g -O0",
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
release => "-O2")),
|
|
|
|
|
cflags => add_before("-DL_ENDIAN -include \$(SRCDIR)/os-dep/haiku.h",
|
2016-05-01 12:33:19 +00:00
|
|
|
threads("-D_REENTRANT")),
|
|
|
|
|
sys_id => "HAIKU",
|
|
|
|
|
ex_libs => "-lnetwork",
|
|
|
|
|
perlasm_scheme => "elf",
|
|
|
|
|
thread_scheme => "pthreads",
|
|
|
|
|
dso_scheme => "dlfcn",
|
|
|
|
|
shared_target => "gnu-shared",
|
|
|
|
|
shared_cflag => "-fPIC",
|
|
|
|
|
shared_ldflag => "-shared",
|
Rework building: Unix changes to handle extensions and product names
Add platform::Unix, which is a generic Unix module to support product
name and extensions functionlity. However, this isn't quite enough,
as mingw and Cygwin builds are done using the same templates, but
since shared libraries work as on Windows and are named accordingly,
platform::mingw and platform::Cygwin were also added to provide the
necessary tweaks.
This reworks Configurations/unix-Makefile.tmpl to work out product
names in platform::Unix et al terms. In this one, we currently do
care about the *_extension config attributes, and the modules adapt
accordingly where it matters.
This change also affected crypto/include/internal/dso_conf.h.in, since
the DSO extension is meant to be the same as the short shared library
extension, which isn't '.so' everywhere.
'shared_extension' attributes that had the value
'.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides
an extension where the shared library version number is hard-coded
instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
2018-10-23 13:09:57 +00:00
|
|
|
perl_platform => 'Unix',
|
2016-05-01 12:33:19 +00:00
|
|
|
},
|
|
|
|
|
"haiku-x86" => {
|
|
|
|
|
inherit_from => [ "haiku-common", asm("x86_elf_asm") ],
|
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
2018-03-06 19:35:30 +00:00
|
|
|
CFLAGS => add(picker(release => "-fomit-frame-pointer")),
|
2016-05-01 12:33:19 +00:00
|
|
|
bn_ops => "BN_LLONG",
|
|
|
|
|
},
|
|
|
|
|
"haiku-x86_64" => {
|
|
|
|
|
inherit_from => [ "haiku-common" ],
|
|
|
|
|
cflags => add("-m64"),
|
|
|
|
|
bn_ops => "SIXTY_FOUR_BIT_LONG",
|
|
|
|
|
},
|
|
|
|
|
);
|