]>
Commit | Line | Data |
---|---|---|
e20ba0a5 RL |
1 | =pod |
2 | ||
3 | =head1 NAME | |
4 | ||
5 | build.info - Building information files | |
6 | ||
7 | =head1 SYNOPSIS | |
8 | ||
9 | B<IF[>0|1B<]> | |
10 | ||
11 | B<ELSIF[>0|1B<]> | |
12 | ||
13 | B<ELSE> | |
14 | ||
15 | B<ENDIF> | |
16 | ||
17 | B<SUBDIRS=> I<dir> ... | |
18 | ||
19 | B<PROGRAMS=> I<name> ... | |
20 | ||
21 | B<LIBS=> I<name> ... | |
22 | ||
23 | B<MODULES=> I<name> ... | |
24 | ||
25 | B<SCRIPTS=> I<name> ... | |
26 | ||
ad5be194 | 27 | B<DEPEND[>I<items>B<]=> I<otheritem> ... |
e20ba0a5 RL |
28 | |
29 | B<GENERATE[>I<item>B<]=> I<generator> I<generator-args> ... | |
30 | ||
31 | B<SOURCE[>I<item>B<]=> I<file> ... | |
32 | ||
33 | B<SHARED_SOURCE[>I<item>B<]=> I<file> ... | |
34 | ||
ad5be194 | 35 | B<DEFINE[>I<items>B<]=> I<name>[B<=>I<value>] ... |
e20ba0a5 | 36 | |
ad5be194 | 37 | B<INCLUDE[>I<items>B<]=> I<dir> ... |
e20ba0a5 RL |
38 | |
39 | B<$>I<VARIABLE>B<=>I<value> | |
40 | ||
41 | =head1 DESCRIPTION | |
42 | ||
43 | OpenSSL's build system revolves around three questions: | |
44 | ||
45 | =over 4 | |
46 | ||
47 | =item What to build for? | |
48 | ||
49 | This is about choice of platform (combination of hardware, operating | |
50 | system, and toolchain). | |
51 | ||
52 | =item What to build? | |
53 | ||
54 | This is about having all the information on what needs to be built and | |
55 | from what. | |
56 | ||
57 | =item How to build it? | |
58 | ||
59 | This is about build file generation. | |
60 | ||
61 | =back | |
62 | ||
63 | This document is all about the second item, "What to build?", and most | |
64 | of all, how to specify that information. | |
65 | ||
66 | For some terms used in this document, please see the L</GLOSSARY> at | |
67 | the end. | |
68 | ||
69 | =head2 F<build.info> files | |
70 | ||
71 | F<build.info> files are meta data files for OpenSSL's built file | |
72 | generators, and are used to specify exactly what end product files | |
73 | (programs, libraries, modules or scripts) are to be produced, and from | |
74 | what sources. | |
75 | ||
79c44b4e | 76 | Intermediate files, such as object files, are seldom referred to at |
e20ba0a5 RL |
77 | all. They sometimes can be, if there's a need, but this should happen |
78 | very rarely, and support for that sort of thing is added on as-needed | |
79 | basis. | |
80 | ||
81 | Any time a directory or file is expected in a statement value, Unix | |
82 | syntax must be used, which means that the slash C</> must be used as | |
83 | the directory separator. | |
84 | ||
85 | =head2 General syntax | |
86 | ||
87 | =head3 Comments | |
88 | ||
89 | Comments are any line that start with a hash sign (C<#>). The hash | |
90 | sign may be preceded by any number of horizontal spaces. | |
91 | ||
92 | =head3 Filenames | |
93 | ||
94 | F<build.info> files are platform agnostic. This means that there is | |
95 | some information in them that is representative rather than specific. | |
96 | ||
97 | This is particularly visible with end product names, they work more | |
98 | like a tag than as the actual filename that's going to be produced. | |
99 | This is because different platforms have different decorations on | |
100 | different types of files. | |
101 | ||
102 | For example, if we say that we want to produce a program C<foo>, it | |
103 | would look like this: | |
104 | ||
105 | PROGRAM=foo | |
106 | ||
107 | However, the program filename may end up being just C<foo> (typical | |
108 | for Unix), or C<foo.exe> (typical for Windows), or even C<BLAH$FOO.EXE> | |
109 | (possible on VMS, depending on policy). | |
110 | ||
111 | These platform specific decorations are not the concern of | |
112 | F<build.info> files. The build file generators are responsible for | |
113 | transforming these platform agnostic names to their platform specific | |
114 | counterparts. | |
115 | ||
116 | =head3 Statements | |
117 | ||
118 | With the exception of variables and conditions, the general statement | |
119 | syntax is one of: | |
120 | ||
121 | =over 4 | |
122 | ||
123 | =item B<I<KEYWORD>> B<=> I<value> ... | |
124 | ||
ad5be194 | 125 | =item B<I<KEYWORD>[>I<items>B<]> B<=> I<value> ... |
e20ba0a5 RL |
126 | |
127 | =back | |
128 | ||
129 | Every B<I<KEYWORD>> represents some particular type of information. | |
130 | ||
131 | The first form (sometimes called "plain statement") is used to specify | |
132 | information on what end products need to be built, for example: | |
133 | ||
134 | PROGRAMS=foo bar | |
135 | LIBS=libpoly libcookie | |
136 | MODULES=awesome-plugin | |
137 | SCRIPTS=tool1 tool2 | |
138 | SUBDIRS=dir1 dir2 | |
139 | ||
140 | This says that we want to build programs C<foo> and C<bar>, the | |
141 | libraries C<libpoly> and C<libcookie>, an awesome plugin module | |
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 | |
144 | C<dir1> and C<dir2>. | |
145 | ||
146 | The second form (sometimes called "indexed statement") is used to | |
147 | specify further details for existing items, for example: | |
148 | ||
149 | SOURCE[foo]=foo.c details.c | |
150 | DEPEND[foo]=libcookie | |
151 | ||
152 | This says that the program C<foo> is built from the source files | |
153 | F<foo.c> and F<details.c>, and that it depends on the library | |
154 | C<libcookie> (in other words, the library will be included when | |
155 | linking that program together). | |
156 | ||
ad5be194 RL |
157 | Multiple space separated items are allowed too: |
158 | ||
159 | SOURCE[foo]=foo.c | |
160 | SOURCE[details]=details.c | |
161 | DEPEND[foo details]=libcookie | |
162 | ||
163 | For any indexed statement for which the items haven't been specified | |
164 | through any plain statement, or where the items exists but the indexed | |
e20ba0a5 RL |
165 | statement does not apply, the value is simply ignored by the build |
166 | file generators. | |
167 | ||
168 | =head3 Statement attributes | |
169 | ||
170 | Some statements can have attributes added to them, to allow for | |
171 | variations on how they are treated. | |
172 | ||
173 | =over 4 | |
174 | ||
7c3ccd7f | 175 | =item B<I<KEYWORD>{> I<attrib> | I<attrib>B<=>I<attrib-value> [,...]B<}> |
e20ba0a5 RL |
176 | B<=> I<value> ... |
177 | ||
ad5be194 | 178 | =item B<I<KEYWORD>[>I<items>B<]{> I<attrib> | I<attrib>B<=>I<attrib-value> |
7c3ccd7f RL |
179 | [,...]B<}> B<=> I<value> ... |
180 | ||
e20ba0a5 RL |
181 | =back |
182 | ||
183 | Attributes are passed as they are to the build file generators, and | |
184 | the exact interpretation of those attributes is entirely up to them | |
185 | (see L</Known attributes> below for details). | |
186 | ||
187 | A current example: | |
188 | ||
189 | LIBS{noinst,has_main}=libtestutil.a | |
190 | ||
191 | This says that the static library C<libtestutil.a> should not be | |
192 | installed (C<noinst>), and that it includes an object file that has | |
193 | the C<main> symbol (C<has_main>). Most platforms don't need to know | |
194 | the latter, but there are some where the program linker will not look | |
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 | |
197 | options to make that happen. | |
198 | ||
199 | Attributes are accumulated globally. This means that a library could | |
200 | be given like this in different places: | |
201 | ||
202 | # Location 1 | |
203 | LIBS=libwhatever | |
204 | ||
205 | # Location 2 | |
206 | LIBS{noinst}=libwhatever | |
207 | ||
208 | # Location 3 | |
209 | LIBS{has_main}=libwhatever | |
210 | ||
211 | The end result is that the library C<libwhatever> will have the | |
212 | attributes C<noinst> and C<has_main> attached to it. | |
213 | ||
214 | =head3 Quoting and tokens | |
215 | ||
216 | Statement values are normally split into a list of tokens, separated | |
217 | by spaces. | |
218 | ||
219 | To avoid having a value split up into several tokens, they may be | |
220 | quoted with double (C<">) or single (C<'>) quotes. | |
221 | ||
222 | For example: | |
223 | ||
224 | PROGRAMS=foo "space cadet" bar | |
225 | ||
226 | This says that we sant to build three programs, C<foo>, C<space cadet> | |
227 | and C<bar>. | |
228 | ||
229 | =head3 Conditionals | |
230 | ||
231 | F<build.info> files include a very simple condition system, involving | |
232 | the following keywords: | |
233 | ||
234 | =over 4 | |
235 | ||
236 | =item B<IF[>0|1B<]> | |
237 | ||
238 | =item B<ELSIF[>0|1B<]> | |
239 | ||
240 | =item B<ELSE> | |
241 | ||
242 | =item B<ENDIF> | |
243 | ||
244 | =back | |
245 | ||
246 | This works like any condition system with similar syntax, and the | |
247 | condition value in B<IF> and B<ELSIF> can really be any literal value | |
248 | that perl can interpret as true or false. | |
249 | ||
250 | Conditional statements are nesting. | |
251 | ||
252 | In itself, this is not very powerful, but together with L</Perl nuggets>, | |
253 | it can be. | |
254 | ||
255 | =head3 Variables | |
256 | ||
257 | F<build.info> handles simple variables. They are defined by | |
258 | assignment: | |
259 | ||
260 | =over 4 | |
261 | ||
262 | =item B<$>I<NAME> B<=> I<value> | |
263 | ||
264 | =back | |
265 | ||
266 | These variables can then be used as part of any statement value or | |
267 | indexed statement item. This should be used with some care, as | |
268 | I<variables are expanded into their values before the value they are | |
269 | part of is tokenized>. | |
270 | ||
271 | I<Variable assignment values are not tokenized.> | |
272 | ||
e4292179 RL |
273 | Variable references can be one of: |
274 | ||
275 | =over 4 | |
276 | ||
277 | =item B<$>I<NAME> or B<${>I<NAME>B<}> | |
278 | ||
279 | Simple reference; the variable reference is replaced with its value, | |
280 | verbatim. | |
281 | ||
282 | =item B<${>I<NAME>B</>I<str>B</>I<subst>B<}> | |
283 | ||
284 | Substitution reference; the variable reference is replaced with its | |
285 | value, modified by replacing all occurences of I<str> with I<subst>. | |
286 | ||
287 | =back | |
288 | ||
e20ba0a5 RL |
289 | =head2 Scope |
290 | ||
291 | Most of the statement values are accumulated globally from all the | |
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. | |
295 | ||
296 | =head2 Perl nuggets | |
297 | ||
298 | Whenever a F<build.info> file is read, it is passed through the Perl | |
299 | template processor L<OpenSSL::Template>, which is a small extension of | |
300 | L<Text::Template>. | |
301 | ||
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> | |
305 | statements, and is most often seen used together with the B<IF> and | |
306 | B<ELSIF> conditional statements. | |
307 | ||
308 | For example: | |
309 | ||
310 | IF[{- $disabled{something} -}] | |
311 | # do whatever's needed when "something" is disabled | |
312 | ELSIF[{- $somethingelse eq 'blah' -}] | |
313 | # do whatever's needed to satisfy this condition | |
314 | ELSE | |
315 | # fallback | |
316 | ENDIF | |
317 | ||
318 | Normal Perl scope applies, so it's possible to have an initial perl | |
319 | nugget that sets diverse global variables that are used in later | |
320 | nuggets. Each nugget is a Perl block of its own, so B<my> definitions | |
321 | are only in scope within the same nugget, while B<our> definitions are | |
322 | in scope within the whole F<build.info> file. | |
323 | ||
324 | =head1 REFERENCE | |
325 | ||
326 | =head2 Conditionals | |
327 | ||
328 | =over 4 | |
329 | ||
330 | =item B<IF[>0|1B<]> | |
331 | ||
332 | If the condition is true (represented as C<1> here), everything | |
333 | between this B<IF> and the next corresponding B<ELSIF> or B<ELSE> | |
334 | applies, and the rest until the corresponding B<ENDIF> is skipped | |
335 | over. | |
336 | ||
337 | If the condition is false (represented as C<0> here), everything | |
338 | from this B<IF> is skipped over until the next corresponding B<ELSIF> | |
339 | or B<ELSE>, at which point processing continues. | |
340 | ||
341 | =item B<ELSE> | |
342 | ||
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 | |
345 | again following this line. | |
346 | ||
347 | =item B<ELSIF[>0|1B<]> | |
348 | ||
349 | This is B<ELSE> and B<IF> combined. | |
350 | ||
351 | =item B<ENDIF> | |
352 | ||
353 | Marks the end of a conditional. | |
354 | ||
355 | =back | |
356 | ||
357 | =head2 Plain statements | |
358 | ||
359 | =over 4 | |
360 | ||
361 | =item B<SUBDIRS=> I<dir> ... | |
362 | ||
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. | |
366 | ||
367 | =item B<PROGRAMS=> I<name> ... | |
368 | ||
369 | Collects names of programs that should be built. | |
370 | ||
371 | B<PROGRAMS> statements may have attributes, which apply to all the | |
372 | programs given in such a statement. For example: | |
373 | ||
374 | PROGRAMS=foo | |
375 | PROGRAMS{noinst}=bar | |
376 | ||
377 | With those two lines, the program C<foo> will not have the attribute | |
378 | C<noinst>, while the program C<bar> will. | |
379 | ||
380 | =item B<LIBS=> I<name> ... | |
381 | ||
382 | Collects names of libraries that should be built. | |
383 | ||
384 | The normal case is that libraries are built in both static and shared | |
385 | form. However, if a name ends with C<.a>, only the static form will | |
386 | be produced. | |
387 | ||
388 | Similarly, libraries may be referred in indexed statements as just the | |
389 | plain name, or the name including the ending C<.a>. If given without | |
390 | the ending C<.a>, any form available will be used, but if given with | |
391 | the ending C<.a>, the static library form is used unconditionally. | |
392 | ||
393 | B<LIBS> statements may have attributes, which apply to all the | |
394 | libraries given in such a statement. For example: | |
395 | ||
396 | LIBS=libfoo | |
397 | LIBS{noinst}=libbar | |
398 | ||
399 | With those two lines, the library C<libfoo> will not have the | |
400 | attribute C<noinst>, while the library C<libbar> will. | |
401 | ||
402 | =item B<MODULES=> I<name> | |
403 | ||
404 | Collects names of dynamically loadable modules that should be built. | |
405 | ||
406 | B<MODULES> statements may have attributes, which apply to all the | |
407 | modules given in such a statement. For example: | |
408 | ||
409 | MODULES=foo | |
410 | MODULES{noinst}=bar | |
411 | ||
412 | With those two lines, the module C<foo> will not have the attribute | |
413 | C<noinst>, while the module C<bar> will. | |
414 | ||
415 | =item B<SCRIPTS=> I<name> | |
416 | ||
417 | Collects names of scripts that should be built, or that just exist. | |
418 | That is how they differ from programs, as programs are always expected | |
419 | to be compiled from multiple sources. | |
420 | ||
421 | B<SCRIPTS> statements may have attributes, which apply to all the | |
422 | scripts given in such a statement. For example: | |
423 | ||
424 | SCRIPTS=foo | |
425 | SCRIPTS{noinst}=bar | |
426 | ||
427 | With those two lines, the script C<foo> will not have the attribute | |
428 | C<noinst>, while the script C<bar> will. | |
429 | ||
430 | =back | |
431 | ||
432 | =head2 Indexed statements | |
433 | ||
434 | =over 4 | |
435 | ||
ad5be194 | 436 | =item B<DEPEND[>I<items>B<]> B<=> I<file> ... |
e20ba0a5 | 437 | |
ad5be194 | 438 | Collects dependencies, where I<items> depend on the given I<file>s. |
e20ba0a5 | 439 | |
ad5be194 | 440 | As a special case, the I<items> may be empty, for which the build file |
e20ba0a5 | 441 | generators should make the whole build depend on the given I<file>s, |
ad5be194 | 442 | rather than the specific I<items>. |
e20ba0a5 | 443 | |
ad5be194 | 444 | The I<items> may be any program, library, module, script, or any |
e20ba0a5 RL |
445 | filename used as a value anywhere. |
446 | ||
7c3ccd7f RL |
447 | B<DEPEND> statements may have attributes, which apply to each |
448 | individual dependency in such a statement. For example: | |
449 | ||
450 | DEPEND[libfoo.a]=libmandatory.a | |
451 | DEPEND[libfoo.a]{weak}=libbar.a libcookie.a | |
452 | ||
453 | With those statements, the dependency between C<libfoo.a> and | |
454 | C<libmandatory.a> is strong, while the dependency between C<libfoo.a> | |
455 | and C<libbar.a> and C<libcookie.a> is weak. See the description of | |
456 | B<weak> in L</Known attributes> for more information. | |
457 | ||
e20ba0a5 RL |
458 | =item B<GENERATE[>I<item>B<]> B<=> I<generator> I<generator-arg> ... |
459 | ||
460 | This specifies that the I<item> is generated using the I<generator> | |
461 | with the I<generator-arg>s as arguments, plus the name of the output | |
462 | file as last argument. | |
463 | ||
464 | For I<generator>s where this is applicable, any B<INCLUDE> statement | |
465 | for the same I<item> will be given to the I<generator> as its | |
70d96753 RL |
466 | inclusion directories. Likewise, any B<DEPEND> statement for the same |
467 | I<item> will be given to the I<generator> as an extra file or module | |
468 | to load, where this is applicable. | |
e20ba0a5 RL |
469 | |
470 | The build file generators must be able to recognise the I<generator>. | |
471 | Currently, they at least recognise files ending in C<.pl>, and will | |
472 | execute them to generate the I<item>, and files ending in C<.in>, | |
473 | which will be used as input for L<OpenSSL::Template> to generate | |
474 | I<item> (in other words, we use the exact same style of | |
475 | L</Perl nuggets> mechanism that is used to read F<build.info> files). | |
476 | ||
477 | =item B<SOURCE[>I<item>B<]> B<=> I<file> ... | |
478 | ||
479 | Collects filenames that will be used as source files for I<item>. | |
480 | ||
481 | The I<item> must be a singular item, and may be any program, library, | |
482 | module or script given with B<PROGRAMS>, B<LIBS>, B<MODULES> and | |
483 | B<SCRIPTS>. | |
484 | ||
7c3ccd7f RL |
485 | Static libraries may be sources. In that case, its object files are |
486 | used directly when building I<item> instead of relying on library | |
487 | dependency and symbol resolution (through B<DEPEND> statements). | |
488 | ||
e20ba0a5 RL |
489 | =item B<SHARED_SOURCE[>I<item>B<]> B<=> I<file> ... |
490 | ||
491 | Collects filenames that will be used as source files for I<item>. | |
492 | ||
493 | The I<item> must be a singular item, and may be any library or module | |
494 | given with B<LIBS> or B<MODULES>. For libraries, the given filenames | |
495 | are only used for their shared form, so if the item is a library name | |
496 | ending with C<.a>, the filenames will be ignored. | |
497 | ||
ad5be194 | 498 | =item B<DEFINE[>I<items>B<]> B<=> I<name>[B<=>I<value>] ... |
e20ba0a5 RL |
499 | |
500 | Collects I<name> / I<value> pairs (or just I<name> with no defined | |
ad5be194 | 501 | value if no I<value> is given) associated with I<items>. |
e20ba0a5 RL |
502 | |
503 | The build file generators will decide what to do with them. For | |
504 | example, these pairs should become C macro definitions whenever a | |
505 | C<.c> file is built into an object file. | |
506 | ||
ad5be194 | 507 | =item B<INCLUDE[>I<items>B<]> B<=> I<dir> ... |
e20ba0a5 RL |
508 | |
509 | Collects inclusion directories that will be used when building the | |
ad5be194 | 510 | I<items> components (object files and whatever else). This is used at |
e20ba0a5 RL |
511 | the discretion of the build file generators. |
512 | ||
513 | =back | |
514 | ||
515 | =head2 Known attributes | |
516 | ||
517 | Note: this will never be a complete list of attributes. | |
518 | ||
519 | =over 4 | |
520 | ||
521 | =item B<noinst> | |
522 | ||
523 | This is used to specify that the end products this is set for should | |
524 | not be installed, that they are only internal. This is applicable on | |
525 | internal static libraries, or on test programs. | |
526 | ||
527 | =item B<misc> | |
528 | ||
529 | This is used with B<SCRIPTS>, to specify that some scripts should be | |
530 | installed in the "misc" directory rather than the normal program | |
531 | directory. | |
532 | ||
533 | =item B<engine> | |
534 | ||
535 | This is used with B<MODULES>, to specify what modules are engines and | |
536 | should be installed in the engines directory instead of the modules | |
537 | directory. | |
538 | ||
7c3ccd7f RL |
539 | =item B<weak> |
540 | ||
541 | This is used with B<DEPEND> where libraries are involved, to specify | |
542 | that the dependency between two libraries is weak and is only there to | |
543 | infer order. | |
544 | ||
545 | Without this attribute, a dependency between two libraries, expressed | |
546 | like this, means that if C<libfoo.a> appears in a linking command | |
547 | line, so will C<libmandatory.a>: | |
548 | ||
549 | DEPEND[libfoo.a]=libmandatory.a | |
550 | ||
551 | With this attribute, a dependency between two libraries, expressed | |
552 | like this, means that if I<both> C<libfoo.a> and C<libmandatory.a> | |
553 | appear in a linking command line (because of recursive dependencies | |
554 | through other libraries), they will be ordered in such a way that this | |
555 | dependency is maintained: | |
556 | ||
557 | DEPEND[libfoo.a]{weak}=libfoo.a libcookie.a | |
558 | ||
79c44b4e | 559 | This is useful in complex dependency trees where two libraries can be |
7c3ccd7f RL |
560 | used as alternatives for each other. In this example, C<lib1.a> and |
561 | C<lib2.a> have alternative implementations of the same thing, and | |
562 | C<libmandatory.a> has unresolved references to that same thing, and is | |
563 | therefore depending on either of them, but not both at the same time: | |
564 | ||
565 | DEPEND[program1]=libmandatory.a lib1.a | |
566 | DEPEND[program2]=libmandatory.a lib2.a | |
567 | DEPEND[libmandatory]{weak}=lib1.a lib2.a | |
568 | ||
e20ba0a5 RL |
569 | =back |
570 | ||
571 | =head1 GLOSSARY | |
572 | ||
573 | =over 4 | |
574 | ||
575 | =item "build file" | |
576 | ||
577 | This is any platform specific file that describes the complete build, | |
578 | with platform specific commands. On Unix, this is typically | |
579 | F<Makefile>; on VMS, this is typically F<descrip.mms>. | |
580 | ||
581 | =item "build file generator" | |
582 | ||
583 | Perl code that generates build files, given configuration data and | |
584 | data collected from F<build.info> files. | |
585 | ||
586 | =item "plain statement" | |
587 | ||
588 | Any F<build.info> statement of the form B<I<KEYWORD>>=I<values>, with | |
589 | the exception of conditional statements and variable assignments. | |
590 | ||
591 | =item "indexed statement" | |
592 | ||
ad5be194 | 593 | Any F<build.info> statement of the form B<I<KEYWORD>[>I<items>B<]=>I<values>, |
e20ba0a5 RL |
594 | with the exception of conditional statements. |
595 | ||
596 | =item "intermediate file" | |
597 | ||
598 | Any file that's an intermediate between a source file and an end | |
599 | product. | |
600 | ||
601 | =item "end product" | |
602 | ||
603 | Any file that is mentioned in the B<PROGRAMS>, B<LIBS>, B<MODULES> or | |
604 | B<SCRIPTS>. | |
605 | ||
606 | =back | |
607 | ||
608 | =head1 SEE ALSO | |
609 | ||
610 | For OpenSSL::Template documentation, | |
611 | C<perldoc -o man util/perl/OpenSSL/Template.pm> | |
612 | ||
613 | L<Text::Temlate|https://metacpan.org/pod/Text::Template> | |
614 | ||
615 | =head1 COPYRIGHT | |
616 | ||
617 | Copyright 2019 The OpenSSL Project Authors. All Rights Reserved. | |
618 | ||
619 | Licensed under the Apache License 2.0 (the "License"). You may not use this | |
620 | file except in compliance with the License. You can obtain a copy in the file | |
621 | LICENSE in the source distribution or at | |
622 | L<https://www.openssl.org/source/license.html>. | |
623 | ||
624 | =cut |