few possible exceptions [1]) have information about end products (such
as scripts, library files and programs) and source files (such as C
files, C header files, assembler files, etc). Intermediate files such
-as object files are rarely directly refered to in build.info files (and
+as object files are rarely directly referred to in build.info files (and
when they are, it's always with the file name extension .o), they are
-infered by Configure. By the same rule of minimalism, end product
+inferred by Configure. By the same rule of minimalism, end product
file name extensions (such as .so, .a, .exe, etc) are never mentioned
-in build.info. Their file name extensions will be infered by the
+in build.info. Their file name extensions will be inferred by the
build-file templates, adapted for the platform they are meant for (see
sections on %unified_info and build-file templates further down).
-The variables PROGRAMS, LIBS, ENGINES and SCRIPTS are used to declare
-end products.
+The variables PROGRAMS, LIBS, MODULES and SCRIPTS are used to declare
+end products. There are variants for them with '_NO_INST' as suffix
+(PROGRAM_NO_INST etc) to specify end products that shouldn't get
+installed.
-The variables SOURCE, DEPEND, INCLUDE and ORDINALS are indexed by a
+The variables SOURCE, DEPEND, INCLUDE and DEFINE are indexed by a
produced file, and their values are the source used to produce that
particular produced file, extra dependencies, include directories
-needed, and ordinal files (explained further below.
+needed, or C macros to be defined.
All their values in all the build.info throughout the source tree are
-collected together and form a set of programs, libraries, engines and
+collected together and form a set of programs, libraries, modules and
scripts to be produced, source files, dependencies, etc etc etc.
Let's have a pretend example, a very limited contraption of OpenSSL,
composed of the program 'apps/openssl', the libraries 'libssl' and
-'libcrypto', an engine 'engines/ossltest' and their sources and
+'libcrypto', an module 'engines/ossltest' and their sources and
dependencies.
# build.info
LIBS=libcrypto libssl
- ORDINALS[libcrypto]=crypto
- ORDINALS[libssl]=ssl
INCLUDE[libcrypto]=include
INCLUDE[libssl]=include
DEPEND[libssl]=libcrypto
This is the top directory build.info file, and it tells us that two
-libraries are to be built, there are some ordinals to be used to
-declare what symbols in those libraries are seen as public, the
-include directory 'include/' shall be used throughout when building
-anything that will end up in each library, and that the library
-'libssl' depend on the library 'libcrypto' to function properly.
+libraries are to be built, the include directory 'include/' shall be
+used throughout when building anything that will end up in each
+library, and that the library 'libssl' depend on the library
+'libcrypto' to function properly.
# apps/build.info
PROGRAMS=openssl
LIBS=../libcrypto
SOURCE[../libcrypto]=aes.c evp.c cversion.c
DEPEND[cversion.o]=buildinf.h
-
- BEGINRAW[Makefile(unix)]
- crypto/buildinf.h : Makefile
- perl util/mkbuildinf.h "$(CC) $(CFLAGS)" "$(PLATFORM)" \
- > crypto/buildinf.h
- ENDRAW[Makefile(unix)]
+
+ GENERATE[buildinf.h]=../util/mkbuildinf.pl "$(CC) $(CFLAGS)" "$(PLATFORM)"
+ DEPEND[buildinf.h]=../Makefile
+ DEPEND[../util/mkbuildinf.pl]=../util/Foo.pm
This is the build.info file in 'crypto', and it tells us a little more
about what's needed to produce 'libcrypto'. LIBS is used again to
This build.info file informs us that 'libcrypto' is built from a few
source files, 'crypto/aes.c', 'crypto/evp.c' and 'crypto/cversion.c'.
It also shows us that building the object file inferred from
-'crypto/cversion.c' depends on 'crypto/buildinf.h'. Finally, it
-also shows the possibility to include raw build-file statements in a
-build.info file, in this case showing how 'buildinf.h' is built on
-Unix-like operating systems.
+'crypto/cversion.c' depends on 'crypto/buildinf.h'. Finally, it
+also shows the possibility to declare how some files are generated
+using some script, in this case a perl script, and how such scripts
+can be declared to depend on other files, in this case a perl module.
Two things are worth an extra note:
-'DEPEND[cversion.o]' mentiones an object file. DEPEND indexes is the
+'DEPEND[cversion.o]' mentions an object file. DEPEND indexes is the
only location where it's valid to mention them
-Lines in 'BEGINRAW'..'ENDRAW' sections must always mention files as
-seen from the top directory, no exception.
-
# ssl/build.info
LIBS=../libssl
SOURCE[../libssl]=tls.c
library 'libssl' is built from the source file 'ssl/tls.c'.
# engines/build.info
- ENGINES=libossltest
- SOURCE[libossltest]=e_ossltest.c
- DEPEND[libossltest]=../libcrypto
- INCLUDE[libossltest]=../include
-
-This is the build.info file in 'engines/', telling us that an engine
-called 'engines/libossltest' shall be built, that it's source is
+ MODULES=dasync
+ SOURCE[dasync]=e_dasync.c
+ DEPEND[dasync]=../libcrypto
+ INCLUDE[dasync]=../include
+
+ MODULES_NO_INST=ossltest
+ SOURCE[ossltest]=e_ossltest.c
+ DEPEND[ossltest]=../libcrypto.a
+ INCLUDE[ossltest]=../include
+
+This is the build.info file in 'engines/', telling us that two modules
+called 'engines/dasync' and 'engines/ossltest' shall be built, that
+dasync's source is 'engines/e_dasync.c' and ossltest's source is
'engines/e_ossltest.c' and that the include directory 'include/' may
-be used when building anything that will be part of this engine.
-Finally, the engine 'engines/libossltest' depends on the library
-'libcrypto' to function properly.
+be used when building anything that will be part of these modules.
+Also, both modules depend on the library 'libcrypto' to function
+properly. ossltest is explicitly linked with the static variant of
+the library 'libcrypto'. Finally, only dasync is being installed, as
+ossltest is only for internal testing.
When Configure digests these build.info files, the accumulated
information comes down to this:
LIBS=libcrypto libssl
- ORDINALS[libcrypto]=crypto
SOURCE[libcrypto]=crypto/aes.c crypto/evp.c crypto/cversion.c
DEPEND[crypto/cversion.o]=crypto/buildinf.h
INCLUDE[libcrypto]=include
- ORDINALS[libssl]=ssl
SOURCE[libssl]=ssl/tls.c
INCLUDE[libssl]=include
DEPEND[libssl]=libcrypto
-
+
PROGRAMS=apps/openssl
SOURCE[apps/openssl]=apps/openssl.c
INCLUDE[apps/openssl]=. include
DEPEND[apps/openssl]=libssl
- ENGINES=engines/libossltest
- SOURCE[engines/libossltest]=engines/e_ossltest.c
- DEPEND[engines/libossltest]=libcrypto
- INCLUDE[engines/libossltest]=include
-
- BEGINRAW[Makefile(unix)]
- crypto/buildinf.h : Makefile
- perl util/mkbuildinf.h "$(CC) $(CFLAGS)" "$(PLATFORM)" \
- > crypto/buildinf.h
- ENDRAW[Makefile(unix)]
+ MODULES=engines/dasync
+ SOURCE[engines/dasync]=engines/e_dasync.c
+ DEPEND[engines/dasync]=libcrypto
+ INCLUDE[engines/dasync]=include
+
+ MODULES_NO_INST=engines/ossltest
+ SOURCE[engines/ossltest]=engines/e_ossltest.c
+ DEPEND[engines/ossltest]=libcrypto.a
+ INCLUDE[engines/ossltest]=include
+
+ GENERATE[crypto/buildinf.h]=util/mkbuildinf.pl "$(CC) $(CFLAGS)" "$(PLATFORM)"
+ DEPEND[crypto/buildinf.h]=Makefile
+ DEPEND[util/mkbuildinf.pl]=util/Foo.pm
A few notes worth mentioning:
PROGRAMS may be used to declare programs only.
-ENGINES may be used to declare engines only.
+MODULES may be used to declare modules only.
-The indexes for SOURCE, INCLUDE and ORDINALS must only be end product
-files, such as libraries, programs or engines. The values of SOURCE
-variables must only be source files (possibly generated)
+The indexes for SOURCE must only be end product files, such as
+libraries, programs or modules. The values of SOURCE variables must
+only be source files (possibly generated).
-DEPEND shows a relationship between different end product files, such
-as a program depending on a library, or between an object file and
-some extra source file.
+INCLUDE and DEPEND shows a relationship between different files
+(usually produced files) or between files and directories, such as a
+program depending on a library, or between an object file and some
+extra source file.
When Configure processes the build.info files, it will take it as
truth without question, and will therefore perform very few checks.
pairs. These are directly inferred from the DEPEND
variables in build.info files.
- engines => a list of engines. These are directly inferred from
- the ENGINES variable in build.info files.
+ modules => a list of modules. These are directly inferred from
+ the MODULES variable in build.info files.
+
+ generate => a hash table containing 'file' => [ 'generator' ... ]
+ pairs. These are directly inferred from the GENERATE
+ variables in build.info files.
includes => a hash table containing 'file' => [ 'include' ... ]
pairs. These are directly inferred from the INCLUDE
variables in build.info files.
+ install => a hash table containing 'type' => [ 'file' ... ] pairs.
+ The types are 'programs', 'libraries', 'modules' and
+ 'scripts', and the array of files list the files of
+ that type that should be installed.
+
libraries => a list of libraries. These are directly inferred from
the LIBS variable in build.info files.
- ordinals => a hash table containing 'file' => [ 'word', 'ordfile' ]
- pairs. 'file' and 'word' are directly inferred from
- the ORDINALS variables in build.info files, while the
- file 'ofile' comes from internal knowledge in
- Configure.
-
programs => a list of programs. These are directly inferred from
the PROGRAMS variable in build.info files.
- rawlines => a list of build-file lines. These are a direct copy of
- the BEGINRAW..ENDRAW lines in build.info files. Note:
- only the BEGINRAW..ENDRAW section for the current
- platform are copied, the rest are ignored.
-
scripts => a list of scripts. There are directly inferred from
the SCRIPTS variable in build.info files.
SOURCE variables, and AS source files for programs and
libraries.
+ shared_sources =>
+ a hash table just like 'sources', but only as source
+ files (object files) for building shared libraries.
+
As an example, here is how the build.info files example from the
section above would be digested into a %unified_info table:
[
"libssl",
],
+ "crypto/buildinf.h" =>
+ [
+ "Makefile",
+ ],
"crypto/cversion.o" =>
[
"crypto/buildinf.h",
],
- "engines/libossltest" =>
+ "engines/dasync" =>
[
"libcrypto",
],
+ "engines/ossltest" =>
+ [
+ "libcrypto.a",
+ ],
"libssl" =>
[
"libcrypto",
],
+ "util/mkbuildinf.pl" =>
+ [
+ "util/Foo.pm",
+ ],
},
- "engines" =>
+ "modules" =>
[
- "engines/libossltest",
+ "engines/dasync",
+ "engines/ossltest",
],
+ "generate" =>
+ {
+ "crypto/buildinf.h" =>
+ [
+ "util/mkbuildinf.pl",
+ "\"\$(CC)",
+ "\$(CFLAGS)\"",
+ "\"$(PLATFORM)\"",
+ ],
+ },
"includes" =>
{
"apps/openssl" =>
".",
"include",
],
- "engines/libossltest" =>
+ "engines/ossltest" =>
[
"include"
],
[
"include",
],
+ "util/mkbuildinf.pl" =>
+ [
+ "util",
+ ],
}
- "libraries" =>
- [
- "libcrypto",
- "libssl",
- ],
- "ordinals" =>
+ "install" =>
{
- "libcrypto" =>
+ "modules" =>
[
- "crypto",
- "util/libeay.num",
+ "engines/dasync",
],
- "libssl" =>
+ "libraries" =>
[
- "ssl",
- "util/ssleay.num",
+ "libcrypto",
+ "libssl",
],
- },
- "programs" =>
+ "programs" =>
+ [
+ "apps/openssl",
+ ],
+ },
+ "libraries" =>
[
- "apps/openssl",
+ "libcrypto",
+ "libssl",
],
- "rawlines" =>
+ "programs" =>
[
- "crypto/buildinf.h : Makefile",
- " perl util/mkbuildinf.h \"\$(CC) \$(CFLAGS)\" \"\$(PLATFORM)\" \\"
- " > crypto/buildinf.h"
+ "apps/openssl",
],
"sources" =>
{
[
"crypto/evp.c",
],
+ "engines/e_dasync.o" =>
+ [
+ "engines/e_dasync.c",
+ ],
+ "engines/dasync" =>
+ [
+ "engines/e_dasync.o",
+ ],
"engines/e_ossltest.o" =>
[
"engines/e_ossltest.c",
],
- "engines/libossltest" =>
+ "engines/ossltest" =>
[
"engines/e_ossltest.o",
],
},
);
-As can be seen, everything in %unified_info is fairly simple nuggest
+As can be seen, everything in %unified_info is fairly simple suggest
of information. Still, it tells us that to build all programs, we
must build 'apps/openssl', and to build the latter, we will need to
build all its sources ('apps/openssl.o' in this case) and all the
from static libraries, to programs from object files and libraries,
etc.
+ generatesrc - function that produces build file lines to generate
+ a source file from some input.
+
+ It's called like this:
+
+ generatesrc(src => "PATH/TO/tobegenerated",
+ generator => [ "generatingfile", ... ]
+ generator_incs => [ "INCL/PATH", ... ]
+ generator_deps => [ "dep1", ... ]
+ incs => [ "INCL/PATH", ... ],
+ deps => [ "dep1", ... ],
+ intent => one of "libs", "dso", "bin" );
+
+ 'src' has the name of the file to be generated.
+ 'generator' is the command or part of command to
+ generate the file, of which the first item is
+ expected to be the file to generate from.
+ generatesrc() is expected to analyse and figure out
+ exactly how to apply that file and how to capture
+ the result. 'generator_incs' and 'generator_deps'
+ are include directories and files that the generator
+ file itself depends on. 'incs' and 'deps' are
+ include directories and files that are used if $(CC)
+ is used as an intermediary step when generating the
+ end product (the file indicated by 'src'). 'intent'
+ indicates what the generated file is going to be
+ used for.
+
src2obj - function that produces build file lines to build an
object file from source files and associated data.
incs => [ "INCL/PATH", ... ]
intent => one of "lib", "dso", "bin" );
- 'obj' has the intended object file *without*
- extension, src2obj() is expected to add that.
+ 'obj' has the intended object file with '.o'
+ extension, src2obj() is expected to change it to
+ something more suitable for the platform.
'srcs' has the list of source files to build the
object file, with the first item being the source
file that directly corresponds to the object file.
'lib' has the intended library file name *without*
extension, obj2lib is expected to add that. 'objs'
- has the list of object files (also *without*
- extension) to build this library.
+ has the list of object files to build this library.
- libobj2shlib - function that produces build file lines to build a
+ libobj2shlib - backward compatibility function that's used the
+ same way as obj2shlib (described next), and was
+ expected to build the shared library from the
+ corresponding static library when that was suitable.
+ NOTE: building a shared library from a static
+ library is now DEPRECATED, as they no longer share
+ object files. Attempting to do this will fail.
+
+ obj2shlib - function that produces build file lines to build a
shareable object library file ("libfoo.so" in Unix
- terms) from the corresponding static library file
- or object files.
+ terms) from the corresponding object files.
called like this:
- libobj2shlib(shlib => "PATH/TO/shlibfile",
- lib => "PATH/TO/libfile",
- objs => [ "PATH/TO/objectfile", ... ],
- deps => [ "PATH/TO/otherlibfile", ... ],
- ordinals => [ "word", "/PATH/TO/ordfile" ]);
+ obj2shlib(shlib => "PATH/TO/shlibfile",
+ lib => "PATH/TO/libfile",
+ objs => [ "PATH/TO/objectfile", ... ],
+ deps => [ "PATH/TO/otherlibfile", ... ]);
- 'lib' has the intended library file name *without*
- extension, libobj2shlib is expected to add that.
- 'shlib' has the correcponding shared library name
+ 'lib' has the base (static) library file name
+ *without* extension. This is useful in case
+ supporting files are needed (such as import
+ libraries on Windows).
+ 'shlib' has the corresponding shared library name
*without* extension. 'deps' has the list of other
libraries (also *without* extension) this library
needs to be linked with. 'objs' has the list of
- object files (also *without* extension) to build
- this library. 'ordinals' MAY be present, and when
- it is, its value is an array where the word is
- "crypto" or "ssl" and the file is one of the ordinal
- files util/libeay.num or util/ssleay.num in the
- source directory.
+ object files to build this library.
- This function has a choice; it can use the
- corresponding static library as input to make the
- shared library, or the list of object files.
-
- obj2dynlib - function that produces build file lines to build a
- dynamically loadable library file ("libfoo.so" on
- Unix) from object files.
+ obj2dso - function that produces build file lines to build a
+ dynamic shared object file from object files.
called like this:
- obj2dynlib(lib => "PATH/TO/libfile",
- objs => [ "PATH/TO/objectfile", ... ],
- deps => [ "PATH/TO/otherlibfile",
- ... ]);
+ obj2dso(lib => "PATH/TO/libfile",
+ objs => [ "PATH/TO/objectfile", ... ],
+ deps => [ "PATH/TO/otherlibfile",
+ ... ]);
- This is almost the same as libobj2shlib, but the
+ This is almost the same as obj2shlib, but the
intent is to build a shareable library that can be
- loaded in runtime (a "plugin"...). The differences
- are subtle, one of the most visible ones is that the
- resulting shareable library is produced from object
- files only.
+ loaded in runtime (a "plugin"...).
obj2bin - function that produces build file lines to build an
executable file from object files.
'bin' has the intended executable file name
*without* extension, obj2bin is expected to add
- that. 'objs' has the list of object files (also
- *without* extension) to build this library. 'deps'
- has the list of library files (also *without*
- extension) that the programs needs to be linked
- with.
+ that. 'objs' has the list of object files to build
+ this library. 'deps' has the list of library files
+ (also *without* extension) that the programs needs
+ to be linked with.
in2script - function that produces build file lines to build a
script file from some input.
'sources' has the list of source files to build the
resulting script from.
-Along with the build-file templates is the driving engine
+Along with the build-file templates is the driving template
Configurations/common.tmpl, which looks through all the information in
%unified_info and generates all the rulesets to build libraries,
programs and all intermediate files, using the rule generating
functions defined in the build-file template.
As an example with the smaller build.info set we've seen as an
-example, producing the rules to build 'libssl' would result in the
+example, producing the rules to build 'libcrypto' would result in the
following calls:
- # Note: libobj2shlib will only be called if shared libraries are
+ # Note: obj2shlib will only be called if shared libraries are
# to be produced.
- # Note 2: libobj2shlib gets both the name of the static library
- # and the names of all the object files that go into it. It's up
- # to the implementation to decide which to use as input.
- libobj2shlib(shlib => "libssl",
- lib => "libssl",
- objs => [ "ssl/tls.o" ],
- deps => [ "libcrypto" ]
- ordinals => [ "ssl", "util/ssleay.num" ]);
-
- obj2lib(lib => "libssl"
- objs => [ "ssl/tls.o" ]);
-
- # Note 3: common.tmpl peals off the ".o" extension, as the
- # platform at hand may have a different one.
- src2obj(obj => "ssl/tls"
- srcs => [ "ssl/tls.c" ],
+ # Note 2: obj2shlib must convert the '.o' extension to whatever
+ # is suitable on the local platform.
+ obj2shlib(shlib => "libcrypto",
+ objs => [ "crypto/aes.o", "crypto/evp.o", "crypto/cversion.o" ],
+ deps => [ ]);
+
+ obj2lib(lib => "libcrypto"
+ objs => [ "crypto/aes.o", "crypto/evp.o", "crypto/cversion.o" ]);
+
+ src2obj(obj => "crypto/aes.o"
+ srcs => [ "crypto/aes.c" ],
deps => [ ],
- incs => [ "include" ]);
+ incs => [ "include" ],
+ intent => "lib");
- src2dep(obj => "ssl/tls"
- srcs => [ "ssl/tls.c" ],
- incs => [ "include" ]);
+ src2obj(obj => "crypto/evp.o"
+ srcs => [ "crypto/evp.c" ],
+ deps => [ ],
+ incs => [ "include" ],
+ intent => "lib");
+
+ src2obj(obj => "crypto/cversion.o"
+ srcs => [ "crypto/cversion.c" ],
+ deps => [ "crypto/buildinf.h" ],
+ incs => [ "include" ],
+ intent => "lib");
+
+ generatesrc(src => "crypto/buildinf.h",
+ generator => [ "util/mkbuildinf.pl", "\"$(CC)",
+ "$(CFLAGS)\"", "\"$(PLATFORM)\"" ],
+ generator_incs => [ "util" ],
+ generator_deps => [ "util/Foo.pm" ],
+ incs => [ ],
+ deps => [ ],
+ intent => "lib");
The returned strings from all those calls are then concatenated
together and written to the resulting build-file.
projects / openssl.git / blobdiff