wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
openssl/Configurations/common.tmpl

232 lines
8.7 KiB
Cheetah
Raw Normal View History

unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
{- # -*- Mode: perl -*-
Add developer targets for each subdirectory we have something to build in 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>
2016-04-02 20:26:38 +00:00
use File::Basename;
# A cache of objects for which a recipe has already been generated
my %cache;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
# resolvedepends and reducedepends work in tandem to make sure
# there are no duplicate dependencies and that they are in the
# right order. This is especially used to sort the list of
# libraries that a build depends on.
sub resolvedepends {
my $thing = shift;
my @listsofar = @_; # to check if we're looping
my @list = @{$unified_info{depends}->{$thing}};
my @newlist = ();
if (scalar @list) {
foreach my $item (@list) {
# It's time to break off when the dependency list starts looping
next if grep { $_ eq $item } @listsofar;
push @newlist, $item, resolvedepends($item, @listsofar, $item);
}
}
@newlist;
}
sub reducedepends {
my @list = @_;
my @newlist = ();
while (@list) {
my $item = shift @list;
push @newlist, $item
unless grep { $item eq $_ } @list;
}
@newlist;
}
Pass down inclusion directories to source file generators 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>
2016-03-10 08:04:09 +00:00
# dogenerate is responsible for producing all the recipes that build
# generated source files. It recurses in case a dependency is also a
# generated source file.
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
sub dogenerate {
my $src = shift;
return "" if $cache{$src};
Pass down inclusion directories to source file generators 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>
2016-03-10 08:04:09 +00:00
my $obj = shift;
my $bin = shift;
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
my %opts = @_;
if ($unified_info{generate}->{$src}) {
Communicate Configure generated header files to build files 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>
2016-05-16 12:54:39 +00:00
die "$src is generated by Configure, should not appear in build file\n"
if ref $unified_info{generate}->{$src} eq "";
Build system: add include directories and dependencies for generators 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>
2016-04-21 12:30:08 +00:00
my $script = $unified_info{generate}->{$src}->[0];
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
$OUT .= generatesrc(src => $src,
generator => $unified_info{generate}->{$src},
Build system: add include directories and dependencies for generators 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>
2016-04-21 12:30:08 +00:00
generator_incs => $unified_info{includes}->{$script},
generator_deps => $unified_info{depends}->{$script},
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
deps => $unified_info{depends}->{$src},
Pass down inclusion directories to source file generators 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>
2016-03-10 08:04:09 +00:00
incs => [ @{$unified_info{includes}->{$bin}},
@{$unified_info{includes}->{$obj}} ],
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
%opts);
foreach (@{$unified_info{depends}->{$src}}) {
Pass down inclusion directories to source file generators 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>
2016-03-10 08:04:09 +00:00
dogenerate($_, $obj, $bin, %opts);
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
}
}
$cache{$src} = 1;
}
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
# doobj is responsible for producing all the recipes that build
# object files as well as dependency files.
sub doobj {
my $obj = shift;
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
return "" if $cache{$obj};
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
(my $obj_no_o = $obj) =~ s|\.o$||;
my $bin = shift;
Always build library object files with shared library cflags 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>
2016-02-19 21:02:41 +00:00
my %opts = @_;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
if (@{$unified_info{sources}->{$obj}}) {
$OUT .= src2obj(obj => $obj_no_o,
srcs => $unified_info{sources}->{$obj},
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
deps => $unified_info{depends}->{$obj},
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
incs => [ @{$unified_info{includes}->{$bin}},
Always build library object files with shared library cflags 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>
2016-02-19 21:02:41 +00:00
@{$unified_info{includes}->{$obj}} ],
%opts);
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
foreach ((@{$unified_info{sources}->{$obj}},
@{$unified_info{depends}->{$obj}})) {
Pass down inclusion directories to source file generators 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>
2016-03-10 08:04:09 +00:00
dogenerate($_, $obj, $bin, %opts);
Unified - Add the build.info command GENERATE, to generate source files 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>
2016-03-07 13:37:00 +00:00
}
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
$cache{$obj} = 1;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
# dolib is responsible for building libraries. It will call
# libobj2shlib is shared libraries are produced, and obj2lib in all
# cases. It also makes sure all object files for the library are
# built.
sub dolib {
my $lib = shift;
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
return "" if $cache{$lib};
Clean away $config{no_shared} since we have $disabled{shared} Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-22 12:52:46 +00:00
unless ($disabled{shared}) {
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
my %ordinals =
$unified_info{ordinals}->{$lib}
? (ordinals => $unified_info{ordinals}->{$lib}) : ();
$OUT .= libobj2shlib(shlib => $unified_info{sharednames}->{$lib},
lib => $lib,
objs => [ map { (my $x = $_) =~ s|\.o$||; $x }
Make it possible to specify source files that will only be used for shared libs 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>
2016-03-29 14:45:03 +00:00
(@{$unified_info{sources}->{$lib}},
@{$unified_info{shared_sources}->{$lib}}) ],
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
deps => [ reducedepends(resolvedepends($lib)) ],
%ordinals);
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
foreach (@{$unified_info{shared_sources}->{$lib}}) {
doobj($_, $lib, intent => "lib");
}
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
$OUT .= obj2lib(lib => $lib,
objs => [ map { (my $x = $_) =~ s|\.o$||; $x }
@{$unified_info{sources}->{$lib}} ]);
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
foreach (@{$unified_info{sources}->{$lib}}) {
doobj($_, $lib, intent => "lib");
}
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
$cache{$lib} = 1;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
# doengine is responsible for building engines. It will call
Small rename fest in unified, obj2dynlib -> obj2dso 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>
2016-02-15 17:45:54 +00:00
# obj2dso, and also makes sure all object files for the library
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
# are built.
sub doengine {
my $lib = shift;
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
return "" if $cache{$lib};
Small rename fest in unified, obj2dynlib -> obj2dso 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>
2016-02-15 17:45:54 +00:00
$OUT .= obj2dso(lib => $lib,
objs => [ map { (my $x = $_) =~ s|\.o$||; $x }
Make it possible to specify source files that will only be used for shared libs 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>
2016-03-29 14:45:03 +00:00
(@{$unified_info{sources}->{$lib}},
@{$unified_info{shared_sources}->{$lib}}) ],
Small rename fest in unified, obj2dynlib -> obj2dso 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>
2016-02-15 17:45:54 +00:00
deps => [ resolvedepends($lib) ]);
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
foreach ((@{$unified_info{sources}->{$lib}},
@{$unified_info{shared_sources}->{$lib}})) {
doobj($_, $lib, intent => "dso");
}
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
$cache{$lib} = 1;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
# dobin is responsible for building programs. It will call obj2bin,
# and also makes sure all object files for the library are built.
sub dobin {
my $bin = shift;
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
return "" if $cache{$bin};
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
my $deps = [ reducedepends(resolvedepends($bin)) ];
$OUT .= obj2bin(bin => $bin,
objs => [ map { (my $x = $_) =~ s|\.o$||; $x }
@{$unified_info{sources}->{$bin}} ],
deps => $deps);
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
foreach (@{$unified_info{sources}->{$bin}}) {
doobj($_, $bin, intent => "bin");
}
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
$cache{$bin} = 1;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
# dobin is responsible for building scripts from templates. It will
# call in2script.
sub doscript {
my $script = shift;
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
return "" if $cache{$script};
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
$OUT .= in2script(script => $script,
sources => $unified_info{sources}->{$script});
Keep a cache of files that already have a recipe, in common.tmpl We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-27 18:12:14 +00:00
$cache{$script} = 1;
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
}
Add developer targets for each subdirectory we have something to build in 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>
2016-04-02 20:26:38 +00:00
sub dodir {
my $dir = shift;
return "" if !exists(&generatedir) or $cache{$dir};
$OUT .= generatedir(dir => $dir,
deps => $unified_info{dirinfo}->{$dir}->{deps},
%{$unified_info{dirinfo}->{$_}->{products}});
$cache{$dir} = 1;
}
Unified - Add the build.info command OVERRIDE, to avoid build file clashes 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>
2016-03-07 13:50:37 +00:00
# Start with populating the cache with all the overrides
%cache = map { $_ => 1 } @{$unified_info{overrides}};
Add developer targets for each subdirectory we have something to build in 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>
2016-04-02 20:26:38 +00:00
# For convenience collect information regarding directories where
# files are generated, those generated files and the end product
# they end up in where applicable. Then, add build rules for those
# directories
if (exists &generatedir) {
my %loopinfo = ( "dso" => [ @{$unified_info{engines}} ],
"lib" => [ @{$unified_info{libraries}} ],
"bin" => [ @{$unified_info{programs}} ],
"script" => [ @{$unified_info{scripts}} ] );
foreach my $type (keys %loopinfo) {
foreach my $product (@{$loopinfo{$type}}) {
my %dirs = ();
my $pd = dirname($product);
Fix the directory target generation 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>
2016-06-05 20:12:04 +00:00
# We already have a "test" target, and the current directory
# is just silly to make a target for
$dirs{$pd} = 1 unless $pd eq "test" || $pd eq ".";
Add developer targets for each subdirectory we have something to build in 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>
2016-04-02 20:26:38 +00:00
foreach (@{$unified_info{sources}->{$product}}) {
my $d = dirname($_);
Fix the directory target generation 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>
2016-06-05 20:12:04 +00:00
# We don't want to create targets for source directories
# when building out of source
next if ($config{sourcedir} ne $config{builddir}
&& $d =~ m|^\Q$config{sourcedir}\E|);
# We already have a "test" target, and the current directory
# is just silly to make a target for
next if $d eq "test" || $d eq ".";
Add developer targets for each subdirectory we have something to build in 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>
2016-04-02 20:26:38 +00:00
$dirs{$d} = 1;
push @{$unified_info{dirinfo}->{$d}->{deps}}, $_
if $d ne $pd;
}
foreach (keys %dirs) {
push @{$unified_info{dirinfo}->{$_}->{products}->{$type}},
$product;
}
}
}
}
Configure: Make it possible to generate mandatory header files '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>
2016-06-13 19:57:51 +00:00
# Build mandatory generated headers
foreach (@{$unified_info{depends}->{""}}) { dogenerate($_); }
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
# Build all known libraries, engines, programs and scripts.
# Everything else will be handled as a consequence.
Perl: foreach (@list) { code } is better Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-04-06 15:30:01 +00:00
foreach (@{$unified_info{libraries}}) { dolib($_); }
foreach (@{$unified_info{engines}}) { doengine($_); }
foreach (@{$unified_info{programs}}) { dobin($_); }
foreach (@{$unified_info{scripts}}) { doscript($_); }
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
Add developer targets for each subdirectory we have something to build in 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>
2016-04-02 20:26:38 +00:00
foreach (sort keys %{$unified_info{dirinfo}}) { dodir($_); }
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
# Finally, should there be any applicable BEGINRAW/ENDRAW sections,
# they are added here.
Perl cleanup: don't create lists unnecessarily Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-06 13:02:57 +00:00
$OUT .= $_."\n" foreach @{$unified_info{rawlines}};
unified build scheme: add and document the "unified" driving engine 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>
2016-01-29 23:57:33 +00:00
-}
Reference in a new issue Copy permalink