Lines Matching +full:build +full:- +full:in
5 build.info - Building information files
29 B<GENERATE[>I<item>B<]=> I<generator> I<generator-args> ...
43 OpenSSL's build system revolves around three questions:
47 =item What to build for?
52 =item What to build?
57 =item How to build it?
59 This is about build file generation.
63 This document is all about the second item, "What to build?", and most
66 For some terms used in this document, please see the L</GLOSSARY> at
69 =head2 F<build.info> files
71 F<build.info> files are meta data files for OpenSSL's built file
78 very rarely, and support for that sort of thing is added on as-needed
81 Any time a directory or file is expected in a statement value, Unix
94 F<build.info> files are platform agnostic. This means that there is
95 some information in them that is representative rather than specific.
112 F<build.info> files. The build file generators are responsible for
136 MODULES=awesome-plugin
140 This says that we want to build programs C<foo> and C<bar>, the
142 C<awesome-plugin>, a couple of scripts C<tool1> and C<tool2>, and
143 finally that there are more F<build.info> files in subdirectories
154 C<libcookie> (in other words, the library will be included when
165 statement does not apply, the value is simply ignored by the build
175 =item B<I<KEYWORD>{> I<attrib> | I<attrib>B<=>I<attrib-value> [,...]B<}>
178 =item B<I<KEYWORD>[>I<items>B<]{> I<attrib> | I<attrib>B<=>I<attrib-value>
183 Attributes are passed as they are to the build file generators, and
195 for C<main> in libraries unless it's explicitly told so, so this is
196 way to tell the build file generator to emit the necessary command
200 be given like this in different places:
226 This says that we sant to build three programs, C<foo>, C<space cadet>
231 F<build.info> files include a very simple condition system, involving
247 condition value in B<IF> and B<ELSIF> can really be any literal value
252 In itself, this is not very powerful, but together with L</Perl nuggets>,
257 F<build.info> handles simple variables. They are defined by
292 F<build.info> files that are digested. There are two exceptions,
293 F<build.info> variables and B<SUBDIRS> statement, for which the scope
294 is the F<build.info> file they are in.
298 Whenever a F<build.info> file is read, it is passed through the Perl
302 Perl nuggets are anything between C<{-> and C<-}>, and whatever the
303 result from such a nugget is, that value will replace the nugget in
304 text form. This is useful to get dynamically generated F<build.info>
310 IF[{- $disabled{something} -}]
312 ELSIF[{- $somethingelse eq 'blah' -}]
319 nugget that sets diverse global variables that are used in later
321 are only in scope within the same nugget, while B<our> definitions are
322 in scope within the whole F<build.info> file.
343 If F<build.info> statements have been skipped over to this point since
344 the corresponding B<IF> or B<ELSIF>, F<build.info> processing starts
363 This instructs the F<build.info> reader to also read the F<build.info>
364 file in every specified directory. All directories should be given
365 relative to the location of the current F<build.info> file.
372 programs given in such a statement. For example:
384 The normal case is that libraries are built in both static and shared
388 Similarly, libraries may be referred in indexed statements as just the
394 libraries given in such a statement. For example:
407 modules given in such a statement. For example:
422 scripts given in such a statement. For example:
440 As a special case, the I<items> may be empty, for which the build file
441 generators should make the whole build depend on the given I<file>s,
447 The I<items> may also be literal build file targets. Those are
454 individual dependency in such a statement. For example:
462 B<weak> in L</Known attributes> for more information.
464 =item B<GENERATE[>I<item>B<]> B<=> I<generator> I<generator-arg> ...
467 with the I<generator-arg>s as arguments, plus the name of the output
476 The build file generators must be able to recognise the I<generator>.
477 Currently, they at least recognise files ending in C<.pl>, and will
478 execute them to generate the I<item>, and files ending in C<.in>,
480 I<item> (in other words, we use the exact same style of
481 L</Perl nuggets> mechanism that is used to read F<build.info> files).
491 Static libraries may be sources. In that case, its object files are
496 individual dependency in such a statement. For example:
523 The build file generators will decide what to do with them. For
531 the discretion of the build file generators.
550 installed in the "misc" directory rather than the normal program
556 should be installed in the engines directory instead of the modules
566 like this, means that if C<libfoo.a> appears in a linking command
573 appear in a linking command line (because of recursive dependencies
574 through other libraries), they will be ordered in such a way that this
579 This is useful in complex dependency trees where two libraries can be
580 used as alternatives for each other. In this example, C<lib1.a> and
595 =item "build file"
597 This is any platform specific file that describes the complete build,
601 =item "build file generator"
603 Perl code that generates build files, given configuration data and
604 data collected from F<build.info> files.
608 Any F<build.info> statement of the form B<I<KEYWORD>>=I<values>, with
613 Any F<build.info> statement of the form B<I<KEYWORD>[>I<items>B<]=>I<values>,
623 Any file that is mentioned in the B<PROGRAMS>, B<LIBS>, B<MODULES> or
631 C<perldoc -o man util/perl/OpenSSL/Template.pm>
637 Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.
640 file except in compliance with the License. You can obtain a copy in the file
641 LICENSE in the source distribution or at