There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones. The best way to
solve this is to separate the two.
Reviewed-by: Andy Polyakov <appro@openssl.org>
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>
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>
As part of this, change util/mkdef.pl to stop adding libraries to
depend on in its output. mkdef.pl should ONLY output a symbol
vector.
Because symbol names can't be longer than 31 characters, we use the
compiler to shorten those that are longer down to 23 characters plus
an 8 character CRC. To make sure users of our header files will pick
up on that automatically, add the DEC C supported extra headers files
__decc_include_prologue.h and __decc_include_epilogue.h.
Furthermore, we add a config.com, so VMS people can configure just as
comfortably as any Unix folks, thusly:
@config
Reviewed-by: Rich Salz <rsalz@openssl.org>
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>
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>
- 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>
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>
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>
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>
