The only thing that makes an ENGINE module special is its entry
points. Other than that, it's a normal dynamically loadable module,
nothing special about it. This change has us stop pretending anything
else.
We retain using ENGINE as a term for installation, because it's
related to a specific installation directory, and we therefore also
mark ENGINE modules specifically as such with an attribute in the
build.info files.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8147)
It was an ugly hack to avoid certain problems that are no more.
Also added GENERATE lines for perlasm scripts that didn't have that
explicitly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8125)
For good measure, we pass down attributes when calling obj2shlib,
obj2lib, obj2dso, obj2bin, or in2script. We currently don't use them
in our build file templates, but might as well for future use.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7581)
Now that we have the names of libraries on different systems
established through platform modules, we can remove the old structure
to establish the same thing, i.e. $unified_info{sharednames} and
$unified_info{rename}. That means removing support for the RENAME and
SHARED_NAME keywords in build.info as well.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
This simple fix allows the following construct:
PROGRAMS=foo
SOURCE[foo]=foo.c bar.c
DEFINE[foo]=FOO=1 BAR=0
These will trickle down to the build of object files, so building
foo.o and bar.o will be done with these options: -DFOO=1 -DBAR=0
(exact syntax depending on platform, of course)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7553)
Sometimes, some specific program or object file might need an extra
macro definition of its own. This allows that to be easily done.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7553)
This makes sure that any resulting directory target in the build files
also depend on object files meant for shared libraries.
As a side effect, we move the production of the dirinfo structure from
common.tmpl to Configure, to make it easier to check the result.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7452)
The possibility to do this was killed when we started producing object
file names with encoded intention (and possibly different builds), and
leads to build errors.
With that, 'libobj2shlib' is renamed to 'obj2shlib' to reflect this
design change. The old name is still used if the new one isn't
available, for the sake of backward compatibility.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7198)
This is in preparation for having separate CFLAGS variables for static
and for shared library builds.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
This will allow to have different object files for different products,
even if they share the same source code, and possibly different builds
for those different object files.
For example, one can have something like this:
SOURCES[libfoo]=cookie.c
INCLUDES[libfoo]=include/foo
SOURCES[libbar]=cookie.c
INCLUDES[libbar]=include/bar
This would mean that the object files and libraries would be build
somewhat like this:
$(CC) -Iinclude/foo -o libfoo-lib-cookie.o cookie.c
$(AR) $(ARFLAGS) libfoo.a libfoo-lib-cookie.o
$(CC) -Iinclude/bar -o libbar-lib-cookie.o cookie.c
$(AR) $(ARFLAGS) libbar.a libbar-lib-cookie.o
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
Instead, use the include settings from the products later in the process,
making it possible to have different includes for two different libraries
that share the same source code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
This ensures that only one set of includes is associated with each
object file, reagardless of where it's used.
For example, if apps/build.info has this:
SOURCE[openssl]=foo.c
INCLUDE[openssl]=.. ../include
and test/build.info has this:
SOURCE[footest]=../apps/foo.c
INCLUDE[footest]=../include
The inclusion directories used for apps/foo.o would differ depending
on which program's dependencies get generated first in the build file.
With this change, all those INCLUDEs get combined into one set of
inclusion directories tied to the object file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5153)
Remove some config attributes that just duplicate values that are
already there in other attributes.
Remove the special runs of mkdef.pl and mkrc.pl from build file
templates, as these are now done via GENERATE statements in
build.info.
Remove all references to ordinal files from build file templates, as
these are now treated via the GENERATE statements in build.info.
Also remove -shared flags and similar that are there in shared-info.pl
anyway. (in the case of darwin, it's mandatory, as -bundle and
-dynamiclib don't mix)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
Because this also includes handling all sorts of non-object files when
linking a program, shared library or DSO, this also includes allowing
general recognition of files such as .res files (compiled from .rc
files), or .def / .map / .opt files (for export and possibly
versioning of public symbols only).
This does mean that there's a tangible change for all build file
templates: they must now recognise and handle the `.o` extension,
which is used internally to recognise object files internally. This
extension was removed by common.tmpl before this change, but would
mean that the platform specific templates wouldn't know if "foo.map"
was originally "foo.map.o" (i.e. an object file in its own right) or
"foo.map" (an export definition file that should be treated as such,
not as an object file).
For the sake of simplifying things, we also modify util/mkdef.pl to
produce .def (Windows) and .opt (VMS) files that don't need additional
hackery.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
Around 138 distinct errors found and fixed; thanks!
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3459)
When building object files for libraries, information whether the
library would be installed or not wasn't passed down to the object
file building rules.
Also, make it so settings like |no_inst_lib_cflags| can be the empty
string.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3247)
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)
Send a bit information to the build file template functions. For
src2obj(), the additional option 'product' holds the name of the final
file that the object file will go into. Additionally, the diverse
functions will get the option 'installed', with a value that evaluates
true if the final product is to be installed, otherwise false.
Reviewed-by: Rich Salz <rsalz@openssl.org>
'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>
The directories for the final products were never registered, it was
plain luck that intermediary files were in the same place and
registered the directory anyway.
Also, scripts are generated directly from source (binaries go through
intermadiary object files), so we need to explicitely make sure to
avoid registering the source directory unless it's an in source
build.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Previous build scheme allowed building just the stuff in one
subdirectory, like this:
make -C crypto/aes
Because the unified only has a top-level Makefile, this is not
possible with it. This change adds a replacement where each directory
we have something to build in becomes a target in its own right,
allowing building something like this:
make crypto/aes
The exception is the directory test, because we already have such a
target.
Reviewed-by: Stephen Henson <steve@openssl.org>
Add Configure generated header files to $unified_info{generate}. This
makes sure the build files will pick them up with the rest for the
GENERATED macro, and thereby make sure they get cleaned away by 'make
clean'
Reviewed-by: Rich Salz <rsalz@openssl.org>
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>
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>
The source file generators sometimes use $(CC) to post-process
generated source, and getting the inclusion directories may be
necessary at times, so we pass them down.
RT#4406
Reviewed-by: Rich Salz <rsalz@openssl.org>
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>
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>
This takes us away from the idea that we know exactly how our static
libraries are going to get used. Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.
On the other hand, we also have greater control of when the shared
library cflags. They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.
With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).
Reviewed-by: Rich Salz <rsalz@openssl.org>
Since we're using the acronym DSO everywhere else and that's a common
name for that kind of object, we might as well do so here as well.
Reviewed-by: Andy Polyakov <appro@openssl.org>
.d (.MMS in the VMS world) files with just dependencies are built from
exactly the same conditions as the object files. Therefore, the rules
for them can be built at the same time as the rules for the
corresponding object files.
This removes the requirement for a src2dep function in the build file
templates, and for common.tmpl to call it. In the end, the existence
of depend files is entirely up to the build file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There was a catch 22, where 'make depend' directly after configuring
in an otherwise pristine build tree would fail because buildinf.h
didn't exist yet.
This change has the depend building targets depend on the same other
targets as the object file building targets, so the generation of
buildinf.h and similar files would kick in during 'make depend'.
Reviewed-by: Rich Salz <rsalz@openssl.org>
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>
