]>
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 | ||
273 | =head2 Scope | |
274 | ||
275 | Most of the statement values are accumulated globally from all the | |
276 | F<build.info> files that are digested. There are two exceptions, | |
277 | F<build.info> variables and B<SUBDIRS> statement, for which the scope | |
278 | is the F<build.info> file they are in. | |
279 | ||
280 | =head2 Perl nuggets | |
281 | ||
282 | Whenever a F<build.info> file is read, it is passed through the Perl | |
283 | template processor L<OpenSSL::Template>, which is a small extension of | |
284 | L<Text::Template>. | |
285 | ||
286 | Perl nuggets are anything between C<{-> and C<-}>, and whatever the | |
287 | result from such a nugget is, that value will replace the nugget in | |
288 | text form. This is useful to get dynamically generated F<build.info> | |
289 | statements, and is most often seen used together with the B<IF> and | |
290 | B<ELSIF> conditional statements. | |
291 | ||
292 | For example: | |
293 | ||
294 | IF[{- $disabled{something} -}] | |
295 | # do whatever's needed when "something" is disabled | |
296 | ELSIF[{- $somethingelse eq 'blah' -}] | |
297 | # do whatever's needed to satisfy this condition | |
298 | ELSE | |
299 | # fallback | |
300 | ENDIF | |
301 | ||
302 | Normal Perl scope applies, so it's possible to have an initial perl | |
303 | nugget that sets diverse global variables that are used in later | |
304 | nuggets. Each nugget is a Perl block of its own, so B<my> definitions | |
305 | are only in scope within the same nugget, while B<our> definitions are | |
306 | in scope within the whole F<build.info> file. | |
307 | ||
308 | =head1 REFERENCE | |
309 | ||
310 | =head2 Conditionals | |
311 | ||
312 | =over 4 | |
313 | ||
314 | =item B<IF[>0|1B<]> | |
315 | ||
316 | If the condition is true (represented as C<1> here), everything | |
317 | between this B<IF> and the next corresponding B<ELSIF> or B<ELSE> | |
318 | applies, and the rest until the corresponding B<ENDIF> is skipped | |
319 | over. | |
320 | ||
321 | If the condition is false (represented as C<0> here), everything | |
322 | from this B<IF> is skipped over until the next corresponding B<ELSIF> | |
323 | or B<ELSE>, at which point processing continues. | |
324 | ||
325 | =item B<ELSE> | |
326 | ||
327 | If F<build.info> statements have been skipped over to this point since | |
328 | the corresponding B<IF> or B<ELSIF>, F<build.info> processing starts | |
329 | again following this line. | |
330 | ||
331 | =item B<ELSIF[>0|1B<]> | |
332 | ||
333 | This is B<ELSE> and B<IF> combined. | |
334 | ||
335 | =item B<ENDIF> | |
336 | ||
337 | Marks the end of a conditional. | |
338 | ||
339 | =back | |
340 | ||
341 | =head2 Plain statements | |
342 | ||
343 | =over 4 | |
344 | ||
345 | =item B<SUBDIRS=> I<dir> ... | |
346 | ||
347 | This instructs the F<build.info> reader to also read the F<build.info> | |
348 | file in every specified directory. All directories should be given | |
349 | relative to the location of the current F<build.info> file. | |
350 | ||
351 | =item B<PROGRAMS=> I<name> ... | |
352 | ||
353 | Collects names of programs that should be built. | |
354 | ||
355 | B<PROGRAMS> statements may have attributes, which apply to all the | |
356 | programs given in such a statement. For example: | |
357 | ||
358 | PROGRAMS=foo | |
359 | PROGRAMS{noinst}=bar | |
360 | ||
361 | With those two lines, the program C<foo> will not have the attribute | |
362 | C<noinst>, while the program C<bar> will. | |
363 | ||
364 | =item B<LIBS=> I<name> ... | |
365 | ||
366 | Collects names of libraries that should be built. | |
367 | ||
368 | The normal case is that libraries are built in both static and shared | |
369 | form. However, if a name ends with C<.a>, only the static form will | |
370 | be produced. | |
371 | ||
372 | Similarly, libraries may be referred in indexed statements as just the | |
373 | plain name, or the name including the ending C<.a>. If given without | |
374 | the ending C<.a>, any form available will be used, but if given with | |
375 | the ending C<.a>, the static library form is used unconditionally. | |
376 | ||
377 | B<LIBS> statements may have attributes, which apply to all the | |
378 | libraries given in such a statement. For example: | |
379 | ||
380 | LIBS=libfoo | |
381 | LIBS{noinst}=libbar | |
382 | ||
383 | With those two lines, the library C<libfoo> will not have the | |
384 | attribute C<noinst>, while the library C<libbar> will. | |
385 | ||
386 | =item B<MODULES=> I<name> | |
387 | ||
388 | Collects names of dynamically loadable modules that should be built. | |
389 | ||
390 | B<MODULES> statements may have attributes, which apply to all the | |
391 | modules given in such a statement. For example: | |
392 | ||
393 | MODULES=foo | |
394 | MODULES{noinst}=bar | |
395 | ||
396 | With those two lines, the module C<foo> will not have the attribute | |
397 | C<noinst>, while the module C<bar> will. | |
398 | ||
399 | =item B<SCRIPTS=> I<name> | |
400 | ||
401 | Collects names of scripts that should be built, or that just exist. | |
402 | That is how they differ from programs, as programs are always expected | |
403 | to be compiled from multiple sources. | |
404 | ||
405 | B<SCRIPTS> statements may have attributes, which apply to all the | |
406 | scripts given in such a statement. For example: | |
407 | ||
408 | SCRIPTS=foo | |
409 | SCRIPTS{noinst}=bar | |
410 | ||
411 | With those two lines, the script C<foo> will not have the attribute | |
412 | C<noinst>, while the script C<bar> will. | |
413 | ||
414 | =back | |
415 | ||
416 | =head2 Indexed statements | |
417 | ||
418 | =over 4 | |
419 | ||
ad5be194 | 420 | =item B<DEPEND[>I<items>B<]> B<=> I<file> ... |
e20ba0a5 | 421 | |
ad5be194 | 422 | Collects dependencies, where I<items> depend on the given I<file>s. |
e20ba0a5 | 423 | |
ad5be194 | 424 | As a special case, the I<items> may be empty, for which the build file |
e20ba0a5 | 425 | generators should make the whole build depend on the given I<file>s, |
ad5be194 | 426 | rather than the specific I<items>. |
e20ba0a5 | 427 | |
ad5be194 | 428 | The I<items> may be any program, library, module, script, or any |
e20ba0a5 RL |
429 | filename used as a value anywhere. |
430 | ||
7c3ccd7f RL |
431 | B<DEPEND> statements may have attributes, which apply to each |
432 | individual dependency in such a statement. For example: | |
433 | ||
434 | DEPEND[libfoo.a]=libmandatory.a | |
435 | DEPEND[libfoo.a]{weak}=libbar.a libcookie.a | |
436 | ||
437 | With those statements, the dependency between C<libfoo.a> and | |
438 | C<libmandatory.a> is strong, while the dependency between C<libfoo.a> | |
439 | and C<libbar.a> and C<libcookie.a> is weak. See the description of | |
440 | B<weak> in L</Known attributes> for more information. | |
441 | ||
e20ba0a5 RL |
442 | =item B<GENERATE[>I<item>B<]> B<=> I<generator> I<generator-arg> ... |
443 | ||
444 | This specifies that the I<item> is generated using the I<generator> | |
445 | with the I<generator-arg>s as arguments, plus the name of the output | |
446 | file as last argument. | |
447 | ||
448 | For I<generator>s where this is applicable, any B<INCLUDE> statement | |
449 | for the same I<item> will be given to the I<generator> as its | |
70d96753 RL |
450 | inclusion directories. Likewise, any B<DEPEND> statement for the same |
451 | I<item> will be given to the I<generator> as an extra file or module | |
452 | to load, where this is applicable. | |
e20ba0a5 RL |
453 | |
454 | The build file generators must be able to recognise the I<generator>. | |
455 | Currently, they at least recognise files ending in C<.pl>, and will | |
456 | execute them to generate the I<item>, and files ending in C<.in>, | |
457 | which will be used as input for L<OpenSSL::Template> to generate | |
458 | I<item> (in other words, we use the exact same style of | |
459 | L</Perl nuggets> mechanism that is used to read F<build.info> files). | |
460 | ||
461 | =item B<SOURCE[>I<item>B<]> B<=> I<file> ... | |
462 | ||
463 | Collects filenames that will be used as source files for I<item>. | |
464 | ||
465 | The I<item> must be a singular item, and may be any program, library, | |
466 | module or script given with B<PROGRAMS>, B<LIBS>, B<MODULES> and | |
467 | B<SCRIPTS>. | |
468 | ||
7c3ccd7f RL |
469 | Static libraries may be sources. In that case, its object files are |
470 | used directly when building I<item> instead of relying on library | |
471 | dependency and symbol resolution (through B<DEPEND> statements). | |
472 | ||
e20ba0a5 RL |
473 | =item B<SHARED_SOURCE[>I<item>B<]> B<=> I<file> ... |
474 | ||
475 | Collects filenames that will be used as source files for I<item>. | |
476 | ||
477 | The I<item> must be a singular item, and may be any library or module | |
478 | given with B<LIBS> or B<MODULES>. For libraries, the given filenames | |
479 | are only used for their shared form, so if the item is a library name | |
480 | ending with C<.a>, the filenames will be ignored. | |
481 | ||
ad5be194 | 482 | =item B<DEFINE[>I<items>B<]> B<=> I<name>[B<=>I<value>] ... |
e20ba0a5 RL |
483 | |
484 | Collects I<name> / I<value> pairs (or just I<name> with no defined | |
ad5be194 | 485 | value if no I<value> is given) associated with I<items>. |
e20ba0a5 RL |
486 | |
487 | The build file generators will decide what to do with them. For | |
488 | example, these pairs should become C macro definitions whenever a | |
489 | C<.c> file is built into an object file. | |
490 | ||
ad5be194 | 491 | =item B<INCLUDE[>I<items>B<]> B<=> I<dir> ... |
e20ba0a5 RL |
492 | |
493 | Collects inclusion directories that will be used when building the | |
ad5be194 | 494 | I<items> components (object files and whatever else). This is used at |
e20ba0a5 RL |
495 | the discretion of the build file generators. |
496 | ||
497 | =back | |
498 | ||
499 | =head2 Known attributes | |
500 | ||
501 | Note: this will never be a complete list of attributes. | |
502 | ||
503 | =over 4 | |
504 | ||
505 | =item B<noinst> | |
506 | ||
507 | This is used to specify that the end products this is set for should | |
508 | not be installed, that they are only internal. This is applicable on | |
509 | internal static libraries, or on test programs. | |
510 | ||
511 | =item B<misc> | |
512 | ||
513 | This is used with B<SCRIPTS>, to specify that some scripts should be | |
514 | installed in the "misc" directory rather than the normal program | |
515 | directory. | |
516 | ||
517 | =item B<engine> | |
518 | ||
519 | This is used with B<MODULES>, to specify what modules are engines and | |
520 | should be installed in the engines directory instead of the modules | |
521 | directory. | |
522 | ||
7c3ccd7f RL |
523 | =item B<weak> |
524 | ||
525 | This is used with B<DEPEND> where libraries are involved, to specify | |
526 | that the dependency between two libraries is weak and is only there to | |
527 | infer order. | |
528 | ||
529 | Without this attribute, a dependency between two libraries, expressed | |
530 | like this, means that if C<libfoo.a> appears in a linking command | |
531 | line, so will C<libmandatory.a>: | |
532 | ||
533 | DEPEND[libfoo.a]=libmandatory.a | |
534 | ||
535 | With this attribute, a dependency between two libraries, expressed | |
536 | like this, means that if I<both> C<libfoo.a> and C<libmandatory.a> | |
537 | appear in a linking command line (because of recursive dependencies | |
538 | through other libraries), they will be ordered in such a way that this | |
539 | dependency is maintained: | |
540 | ||
541 | DEPEND[libfoo.a]{weak}=libfoo.a libcookie.a | |
542 | ||
79c44b4e | 543 | This is useful in complex dependency trees where two libraries can be |
7c3ccd7f RL |
544 | used as alternatives for each other. In this example, C<lib1.a> and |
545 | C<lib2.a> have alternative implementations of the same thing, and | |
546 | C<libmandatory.a> has unresolved references to that same thing, and is | |
547 | therefore depending on either of them, but not both at the same time: | |
548 | ||
549 | DEPEND[program1]=libmandatory.a lib1.a | |
550 | DEPEND[program2]=libmandatory.a lib2.a | |
551 | DEPEND[libmandatory]{weak}=lib1.a lib2.a | |
552 | ||
e20ba0a5 RL |
553 | =back |
554 | ||
555 | =head1 GLOSSARY | |
556 | ||
557 | =over 4 | |
558 | ||
559 | =item "build file" | |
560 | ||
561 | This is any platform specific file that describes the complete build, | |
562 | with platform specific commands. On Unix, this is typically | |
563 | F<Makefile>; on VMS, this is typically F<descrip.mms>. | |
564 | ||
565 | =item "build file generator" | |
566 | ||
567 | Perl code that generates build files, given configuration data and | |
568 | data collected from F<build.info> files. | |
569 | ||
570 | =item "plain statement" | |
571 | ||
572 | Any F<build.info> statement of the form B<I<KEYWORD>>=I<values>, with | |
573 | the exception of conditional statements and variable assignments. | |
574 | ||
575 | =item "indexed statement" | |
576 | ||
ad5be194 | 577 | Any F<build.info> statement of the form B<I<KEYWORD>[>I<items>B<]=>I<values>, |
e20ba0a5 RL |
578 | with the exception of conditional statements. |
579 | ||
580 | =item "intermediate file" | |
581 | ||
582 | Any file that's an intermediate between a source file and an end | |
583 | product. | |
584 | ||
585 | =item "end product" | |
586 | ||
587 | Any file that is mentioned in the B<PROGRAMS>, B<LIBS>, B<MODULES> or | |
588 | B<SCRIPTS>. | |
589 | ||
590 | =back | |
591 | ||
592 | =head1 SEE ALSO | |
593 | ||
594 | For OpenSSL::Template documentation, | |
595 | C<perldoc -o man util/perl/OpenSSL/Template.pm> | |
596 | ||
597 | L<Text::Temlate|https://metacpan.org/pod/Text::Template> | |
598 | ||
599 | =head1 COPYRIGHT | |
600 | ||
601 | Copyright 2019 The OpenSSL Project Authors. All Rights Reserved. | |
602 | ||
603 | Licensed under the Apache License 2.0 (the "License"). You may not use this | |
604 | file except in compliance with the License. You can obtain a copy in the file | |
605 | LICENSE in the source distribution or at | |
606 | L<https://www.openssl.org/source/license.html>. | |
607 | ||
608 | =cut |