1Intro 2===== 3 4This directory contains a few sets of files that are used for 5configuration in diverse ways: 6 7 *.conf Target platform configurations, please read 8 'Configurations of OpenSSL target platforms' for more 9 information. 10 *.tmpl Build file templates, please read 'Build-file 11 programming with the "unified" build system' as well 12 as 'Build info files' for more information. 13 *.pm Helper scripts / modules for the main `Configure` 14 script. See 'Configure helper scripts for more 15 information. 16 17 18Configurations of OpenSSL target platforms 19========================================== 20 21Configuration targets are a collection of facts that we know about 22different platforms and their capabilities. We organise them in a 23hash table, where each entry represent a specific target. 24 25Note that configuration target names must be unique across all config 26files. The Configure script does check that a config file doesn't 27have config targets that shadow config targets from other files. 28 29In each table entry, the following keys are significant: 30 31 inherit_from => Other targets to inherit values from. 32 Explained further below. [1] 33 template => Set to 1 if this isn't really a platform 34 target. Instead, this target is a template 35 upon which other targets can be built. 36 Explained further below. [1] 37 38 sys_id => System identity for systems where that 39 is difficult to determine automatically. 40 41 enable => Enable specific configuration features. 42 This MUST be an array of words. 43 disable => Disable specific configuration features. 44 This MUST be an array of words. 45 Note: if the same feature is both enabled 46 and disabled, disable wins. 47 48 as => The assembler command. This is not always 49 used (for example on Unix, where the C 50 compiler is used instead). 51 asflags => Default assembler command flags [4]. 52 cpp => The C preprocessor command, normally not 53 given, as the build file defaults are 54 usually good enough. 55 cppflags => Default C preprocessor flags [4]. 56 defines => As an alternative, macro definitions may be 57 given here instead of in `cppflags' [4]. 58 If given here, they MUST be as an array of 59 the string such as "MACRO=value", or just 60 "MACRO" for definitions without value. 61 includes => As an alternative, inclusion directories 62 may be given here instead of in `cppflags' 63 [4]. If given here, the MUST be an array 64 of strings, one directory specification 65 each. 66 cc => The C compiler command, usually one of "cc", 67 "gcc" or "clang". This command is normally 68 also used to link object files and 69 libraries into the final program. 70 cxx => The C++ compiler command, usually one of 71 "c++", "g++" or "clang++". This command is 72 also used when linking a program where at 73 least one of the object file is made from 74 C++ source. 75 cflags => Defaults C compiler flags [4]. 76 cxxflags => Default C++ compiler flags [4]. If unset, 77 it gets the same value as cflags. 78 79 (linking is a complex thing, see [3] below) 80 ld => Linker command, usually not defined 81 (meaning the compiler command is used 82 instead). 83 (NOTE: this is here for future use, it's 84 not implemented yet) 85 lflags => Default flags used when linking apps, 86 shared libraries or DSOs [4]. 87 ex_libs => Extra libraries that are needed when 88 linking shared libraries, DSOs or programs. 89 The value is also assigned to Libs.private 90 in $(libdir)/pkgconfig/libcrypto.pc. 91 92 shared_cppflags => Extra C preprocessor flags used when 93 processing C files for shared libraries. 94 shared_cflag => Extra C compiler flags used when compiling 95 for shared libraries, typically something 96 like "-fPIC". 97 shared_ldflag => Extra linking flags used when linking 98 shared libraries. 99 module_cppflags 100 module_cflags 101 module_ldflags => Has the same function as the corresponding 102 `shared_' attributes, but for building DSOs. 103 When unset, they get the same values as the 104 corresponding `shared_' attributes. 105 106 ar => The library archive command, the default is 107 "ar". 108 (NOTE: this is here for future use, it's 109 not implemented yet) 110 arflags => Flags to be used with the library archive 111 command. On Unix, this includes the 112 command letter, 'r' by default. 113 114 ranlib => The library archive indexing command, the 115 default is 'ranlib' it it exists. 116 117 unistd => An alternative header to the typical 118 '<unistd.h>'. This is very rarely needed. 119 120 shared_extension => File name extension used for shared 121 libraries. 122 obj_extension => File name extension used for object files. 123 On unix, this defaults to ".o" (NOTE: this 124 is here for future use, it's not 125 implemented yet) 126 exe_extension => File name extension used for executable 127 files. On unix, this defaults to "" (NOTE: 128 this is here for future use, it's not 129 implemented yet) 130 shlib_variant => A "variant" identifier inserted between the base 131 shared library name and the extension. On "unixy" 132 platforms (BSD, Linux, Solaris, MacOS/X, ...) this 133 supports installation of custom OpenSSL libraries 134 that don't conflict with other builds of OpenSSL 135 installed on the system. The variant identifier 136 becomes part of the SONAME of the library and also 137 any symbol versions (symbol versions are not used or 138 needed with MacOS/X). For example, on a system 139 where a default build would normally create the SSL 140 shared library as 'libssl.so -> libssl.so.1.1' with 141 the value of the symlink as the SONAME, a target 142 definition that sets 'shlib_variant => "-abc"' will 143 create 'libssl.so -> libssl-abc.so.1.1', again with 144 an SONAME equal to the value of the symlink. The 145 symbol versions associated with the variant library 146 would then be 'OPENSSL_ABC_<version>' rather than 147 the default 'OPENSSL_<version>'. The string inserted 148 into symbol versions is obtained by mapping all 149 letters in the "variant" identifier to upper case 150 and all non-alphanumeric characters to '_'. 151 152 thread_scheme => The type of threads is used on the 153 configured platform. Currently known 154 values are "(unknown)", "pthreads", 155 "uithreads" (a.k.a solaris threads) and 156 "winthreads". Except for "(unknown)", the 157 actual value is currently ignored but may 158 be used in the future. See further notes 159 below [2]. 160 dso_scheme => The type of dynamic shared objects to build 161 for. This mostly comes into play with 162 engines, but can be used for other purposes 163 as well. Valid values are "DLFCN" 164 (dlopen() et al), "DLFCN_NO_H" (for systems 165 that use dlopen() et al but do not have 166 fcntl.h), "DL" (shl_load() et al), "WIN32" 167 and "VMS". 168 perlasm_scheme => The perlasm method used to create the 169 assembler files used when compiling with 170 assembler implementations. 171 shared_target => The shared library building method used. 172 This is a target found in Makefile.shared. 173 build_scheme => The scheme used to build up a Makefile. 174 In its simplest form, the value is a string 175 with the name of the build scheme. 176 The value may also take the form of a list 177 of strings, if the build_scheme is to have 178 some options. In this case, the first 179 string in the list is the name of the build 180 scheme. 181 Currently recognised build scheme is "unified". 182 For the "unified" build scheme, this item 183 *must* be an array with the first being the 184 word "unified" and the second being a word 185 to identify the platform family. 186 187 multilib => On systems that support having multiple 188 implementations of a library (typically a 189 32-bit and a 64-bit variant), this is used 190 to have the different variants in different 191 directories. 192 193 bn_ops => Building options (was just bignum options in 194 the earlier history of this option, hence the 195 name). This is a string of words that describe 196 algorithms' implementation parameters that 197 are optimal for the designated target platform, 198 such as the type of integers used to build up 199 the bignum, different ways to implement certain 200 ciphers and so on. To fully comprehend the 201 meaning, the best is to read the affected 202 source. 203 The valid words are: 204 205 THIRTY_TWO_BIT bignum limbs are 32 bits, 206 this is default if no 207 option is specified, it 208 works on any supported 209 system [unless "wider" 210 limb size is implied in 211 assembly code]; 212 BN_LLONG bignum limbs are 32 bits, 213 but 64-bit 'unsigned long 214 long' is used internally 215 in calculations; 216 SIXTY_FOUR_BIT_LONG bignum limbs are 64 bits 217 and sizeof(long) is 8; 218 SIXTY_FOUR_BIT bignums limbs are 64 bits, 219 but execution environment 220 is ILP32; 221 RC4_CHAR RC4 key schedule is made 222 up of 'unsigned char's; 223 RC4_INT RC4 key schedule is made 224 up of 'unsigned int's; 225 EXPORT_VAR_AS_FN for shared libraries, 226 export vars as 227 accessor functions. 228 229 apps_aux_src => Extra source to build apps/openssl and other 230 apps, as needed by the target and that can be 231 collected in a library. 232 apps_init_src => Init source to build apps/openssl and other 233 apps, as needed by the target. This code 234 cannot be placed in a library, as the rest 235 of the code isn't expected to link to it 236 explicitly. 237 cpuid_asm_src => assembler implementation of cpuid code as 238 well as OPENSSL_cleanse(). 239 Default to mem_clr.c 240 bn_asm_src => Assembler implementation of core bignum 241 functions. 242 Defaults to bn_asm.c 243 ec_asm_src => Assembler implementation of core EC 244 functions. 245 des_asm_src => Assembler implementation of core DES 246 encryption functions. 247 Defaults to 'des_enc.c fcrypt_b.c' 248 aes_asm_src => Assembler implementation of core AES 249 functions. 250 Defaults to 'aes_core.c aes_cbc.c' 251 bf_asm_src => Assembler implementation of core BlowFish 252 functions. 253 Defaults to 'bf_enc.c' 254 md5_asm_src => Assembler implementation of core MD5 255 functions. 256 sha1_asm_src => Assembler implementation of core SHA1, 257 functions, and also possibly SHA256 and 258 SHA512 ones. 259 cast_asm_src => Assembler implementation of core CAST 260 functions. 261 Defaults to 'c_enc.c' 262 rc4_asm_src => Assembler implementation of core RC4 263 functions. 264 Defaults to 'rc4_enc.c rc4_skey.c' 265 rmd160_asm_src => Assembler implementation of core RMD160 266 functions. 267 rc5_asm_src => Assembler implementation of core RC5 268 functions. 269 Defaults to 'rc5_enc.c' 270 wp_asm_src => Assembler implementation of core WHIRLPOOL 271 functions. 272 cmll_asm_src => Assembler implementation of core CAMELLIA 273 functions. 274 Defaults to 'camellia.c cmll_misc.c cmll_cbc.c' 275 modes_asm_src => Assembler implementation of cipher modes, 276 currently the functions gcm_gmult_4bit and 277 gcm_ghash_4bit. 278 padlock_asm_src => Assembler implementation of core parts of 279 the padlock engine. This is mandatory on 280 any platform where the padlock engine might 281 actually be built. 282 283 284[1] as part of the target configuration, one can have a key called 285 'inherit_from' that indicate what other configurations to inherit 286 data from. These are resolved recursively. 287 288 Inheritance works as a set of default values that can be overridden 289 by corresponding key values in the inheriting configuration. 290 291 Note 1: any configuration table can be used as a template. 292 Note 2: pure templates have the attribute 'template => 1' and 293 cannot be used as build targets. 294 295 If several configurations are given in the 'inherit_from' array, 296 the values of same attribute are concatenated with space 297 separation. With this, it's possible to have several smaller 298 templates for different configuration aspects that can be combined 299 into a complete configuration. 300 301 instead of a scalar value or an array, a value can be a code block 302 of the form 'sub { /* your code here */ }'. This code block will 303 be called with the list of inherited values for that key as 304 arguments. In fact, the concatenation of strings is really done 305 by using 'sub { join(" ",@_) }' on the list of inherited values. 306 307 An example: 308 309 "foo" => { 310 template => 1, 311 haha => "ha ha", 312 hoho => "ho", 313 ignored => "This should not appear in the end result", 314 }, 315 "bar" => { 316 template => 1, 317 haha => "ah", 318 hoho => "haho", 319 hehe => "hehe" 320 }, 321 "laughter" => { 322 inherit_from => [ "foo", "bar" ], 323 hehe => sub { join(" ",(@_,"!!!")) }, 324 ignored => "", 325 } 326 327 The entry for "laughter" will become as follows after processing: 328 329 "laughter" => { 330 haha => "ha ha ah", 331 hoho => "ho haho", 332 hehe => "hehe !!!", 333 ignored => "" 334 } 335 336[2] OpenSSL is built with threading capabilities unless the user 337 specifies 'no-threads'. The value of the key 'thread_scheme' may 338 be "(unknown)", in which case the user MUST give some compilation 339 flags to Configure. 340 341[3] OpenSSL has three types of things to link from object files or 342 static libraries: 343 344 - shared libraries; that would be libcrypto and libssl. 345 - shared objects (sometimes called dynamic libraries); that would 346 be the engines. 347 - applications; those are apps/openssl and all the test apps. 348 349 Very roughly speaking, linking is done like this (words in braces 350 represent the configuration settings documented at the beginning 351 of this file): 352 353 shared libraries: 354 {ld} $(CFLAGS) {lflags} {shared_ldflag} -o libfoo.so \ 355 foo/something.o foo/somethingelse.o {ex_libs} 356 357 shared objects: 358 {ld} $(CFLAGS) {lflags} {module_ldflags} -o libeng.so \ 359 blah1.o blah2.o -lcrypto {ex_libs} 360 361 applications: 362 {ld} $(CFLAGS) {lflags} -o app \ 363 app1.o utils.o -lssl -lcrypto {ex_libs} 364 365[4] There are variants of these attribute, prefixed with `lib_', 366 `dso_' or `bin_'. Those variants replace the unprefixed attribute 367 when building library, DSO or program modules specifically. 368 369Historically, the target configurations came in form of a string with 370values separated by colons. This use is deprecated. The string form 371looked like this: 372 373 "target" => "{cc}:{cflags}:{unistd}:{thread_cflag}:{sys_id}:{lflags}:{bn_ops}:{cpuid_obj}:{bn_obj}:{ec_obj}:{des_obj}:{aes_obj}:{bf_obj}:{md5_obj}:{sha1_obj}:{cast_obj}:{rc4_obj}:{rmd160_obj}:{rc5_obj}:{wp_obj}:{cmll_obj}:{modes_obj}:{padlock_obj}:{perlasm_scheme}:{dso_scheme}:{shared_target}:{shared_cflag}:{shared_ldflag}:{shared_extension}:{ranlib}:{arflags}:{multilib}" 374 375 376Build info files 377================ 378 379The build.info files that are spread over the source tree contain the 380minimum information needed to build and distribute OpenSSL. It uses a 381simple and yet fairly powerful language to determine what needs to be 382built, from what sources, and other relationships between files. 383 384For every build.info file, all file references are relative to the 385directory of the build.info file for source files, and the 386corresponding build directory for built files if the build tree 387differs from the source tree. 388 389When processed, every line is processed with the perl module 390Text::Template, using the delimiters "{-" and "-}". The hashes 391%config and %target are passed to the perl fragments, along with 392$sourcedir and $builddir, which are the locations of the source 393directory for the current build.info file and the corresponding build 394directory, all relative to the top of the build tree. 395 396To begin with, things to be built are declared by setting specific 397variables: 398 399 PROGRAMS=foo bar 400 LIBS=libsomething 401 ENGINES=libeng 402 SCRIPTS=myhack 403 EXTRA=file1 file2 404 405Note that the files mentioned for PROGRAMS, LIBS and ENGINES *must* be 406without extensions. The build file templates will figure them out. 407 408For each thing to be built, it is then possible to say what sources 409they are built from: 410 411 PROGRAMS=foo bar 412 SOURCE[foo]=foo.c common.c 413 SOURCE[bar]=bar.c extra.c common.c 414 415It's also possible to tell some other dependencies: 416 417 DEPEND[foo]=libsomething 418 DEPEND[libbar]=libsomethingelse 419 420(it could be argued that 'libsomething' and 'libsomethingelse' are 421source as well. However, the files given through SOURCE are expected 422to be located in the source tree while files given through DEPEND are 423expected to be located in the build tree) 424 425It's also possible to depend on static libraries explicitly: 426 427 DEPEND[foo]=libsomething.a 428 DEPEND[libbar]=libsomethingelse.a 429 430This should be rarely used, and care should be taken to make sure it's 431only used when supported. For example, native Windows build doesn't 432support building static libraries and DLLs at the same time, so using 433static libraries on Windows can only be done when configured 434'no-shared'. 435 436One some platforms, shared libraries come with a name that's different 437from their static counterpart. That's declared as follows: 438 439 SHARED_NAME[libfoo]=cygfoo-{- $config{shlibver} -} 440 441The example is from Cygwin, which has a required naming convention. 442 443Sometimes, it makes sense to rename an output file, for example a 444library: 445 446 RENAME[libfoo]=libbar 447 448That line has "libfoo" renamed to "libbar". While it makes no 449sense at all to just have a rename like that (why not just use 450"libbar" everywhere?), it does make sense when it can be used 451conditionally. See a little further below for an example. 452 453In some cases, it's desirable to include some source files in the 454shared form of a library only: 455 456 SHARED_SOURCE[libfoo]=dllmain.c 457 458For any file to be built, it's also possible to tell what extra 459include paths the build of their source files should use: 460 461 INCLUDE[foo]=include 462 463In some cases, one might want to generate some source files from 464others, that's done as follows: 465 466 GENERATE[foo.s]=asm/something.pl $(CFLAGS) 467 GENERATE[bar.s]=asm/bar.S 468 469The value of each GENERATE line is a command line or part of it. 470Configure places no rules on the command line, except that the first 471item must be the generator file. It is, however, entirely up to the 472build file template to define exactly how those command lines should 473be handled, how the output is captured and so on. 474 475Sometimes, the generator file itself depends on other files, for 476example if it is a perl script that depends on other perl modules. 477This can be expressed using DEPEND like this: 478 479 DEPEND[asm/something.pl]=../perlasm/Foo.pm 480 481There may also be cases where the exact file isn't easily specified, 482but an inclusion directory still needs to be specified. INCLUDE can 483be used in that case: 484 485 INCLUDE[asm/something.pl]=../perlasm 486 487NOTE: GENERATE lines are limited to one command only per GENERATE. 488 489As a last resort, it's possible to have raw build file lines, between 490BEGINRAW and ENDRAW lines as follows: 491 492 BEGINRAW[Makefile(unix)] 493 haha.h: {- $builddir -}/Makefile 494 echo "/* haha */" > haha.h 495 ENDRAW[Makefile(unix)] 496 497The word within square brackets is the build_file configuration item 498or the build_file configuration item followed by the second word in the 499build_scheme configuration item for the configured target within 500parenthesis as shown above. For example, with the following relevant 501configuration items: 502 503 build_file => "build.ninja" 504 build_scheme => [ "unified", "unix" ] 505 506... these lines will be considered: 507 508 BEGINRAW[build.ninja] 509 build haha.h: echo "/* haha */" > haha.h 510 ENDRAW[build.ninja] 511 512 BEGINRAW[build.ninja(unix)] 513 build hoho.h: echo "/* hoho */" > hoho.h 514 ENDRAW[build.ninja(unix)] 515 516Should it be needed because the recipes within a RAW section might 517clash with those generated by Configure, it's possible to tell it 518not to generate them with the use of OVERRIDES, for example: 519 520 SOURCE[libfoo]=foo.c bar.c 521 522 OVERRIDES=bar.o 523 BEGINRAW[Makefile(unix)] 524 bar.o: bar.c 525 $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< 526 ENDRAW[Makefile(unix)] 527 528See the documentation further up for more information on configuration 529items. 530 531Finally, you can have some simple conditional use of the build.info 532information, looking like this: 533 534 IF[1] 535 something 536 ELSIF[2] 537 something other 538 ELSE 539 something else 540 ENDIF 541 542The expression in square brackets is interpreted as a string in perl, 543and will be seen as true if perl thinks it is, otherwise false. For 544example, the above would have "something" used, since 1 is true. 545 546Together with the use of Text::Template, this can be used as 547conditions based on something in the passed variables, for example: 548 549 IF[{- $disabled{shared} -}] 550 LIBS=libcrypto 551 SOURCE[libcrypto]=... 552 ELSE 553 LIBS=libfoo 554 SOURCE[libfoo]=... 555 ENDIF 556 557or: 558 559 # VMS has a cultural standard where all libraries are prefixed. 560 # For OpenSSL, the choice is 'ossl_' 561 IF[{- $config{target} =~ /^vms/ -}] 562 RENAME[libcrypto]=ossl_libcrypto 563 RENAME[libssl]=ossl_libssl 564 ENDIF 565 566 567Build-file programming with the "unified" build system 568====================================================== 569 570"Build files" are called "Makefile" on Unix-like operating systems, 571"descrip.mms" for MMS on VMS, "makefile" for nmake on Windows, etc. 572 573To use the "unified" build system, the target configuration needs to 574set the three items 'build_scheme', 'build_file' and 'build_command'. 575In the rest of this section, we will assume that 'build_scheme' is set 576to "unified" (see the configurations documentation above for the 577details). 578 579For any name given by 'build_file', the "unified" system expects a 580template file in Configurations/ named like the build file, with 581".tmpl" appended, or in case of possible ambiguity, a combination of 582the second 'build_scheme' list item and the 'build_file' name. For 583example, if 'build_file' is set to "Makefile", the template could be 584Configurations/Makefile.tmpl or Configurations/unix-Makefile.tmpl. 585In case both Configurations/unix-Makefile.tmpl and 586Configurations/Makefile.tmpl are present, the former takes 587precedence. 588 589The build-file template is processed with the perl module 590Text::Template, using "{-" and "-}" as delimiters that enclose the 591perl code fragments that generate configuration-dependent content. 592Those perl fragments have access to all the hash variables from 593configdata.pem. 594 595The build-file template is expected to define at least the following 596perl functions in a perl code fragment enclosed with "{-" and "-}". 597They are all expected to return a string with the lines they produce. 598 599 generatesrc - function that produces build file lines to generate 600 a source file from some input. 601 602 It's called like this: 603 604 generatesrc(src => "PATH/TO/tobegenerated", 605 generator => [ "generatingfile", ... ] 606 generator_incs => [ "INCL/PATH", ... ] 607 generator_deps => [ "dep1", ... ] 608 generator => [ "generatingfile", ... ] 609 incs => [ "INCL/PATH", ... ], 610 deps => [ "dep1", ... ], 611 intent => one of "libs", "dso", "bin" ); 612 613 'src' has the name of the file to be generated. 614 'generator' is the command or part of command to 615 generate the file, of which the first item is 616 expected to be the file to generate from. 617 generatesrc() is expected to analyse and figure out 618 exactly how to apply that file and how to capture 619 the result. 'generator_incs' and 'generator_deps' 620 are include directories and files that the generator 621 file itself depends on. 'incs' and 'deps' are 622 include directories and files that are used if $(CC) 623 is used as an intermediary step when generating the 624 end product (the file indicated by 'src'). 'intent' 625 indicates what the generated file is going to be 626 used for. 627 628 src2obj - function that produces build file lines to build an 629 object file from source files and associated data. 630 631 It's called like this: 632 633 src2obj(obj => "PATH/TO/objectfile", 634 srcs => [ "PATH/TO/sourcefile", ... ], 635 deps => [ "dep1", ... ], 636 incs => [ "INCL/PATH", ... ] 637 intent => one of "lib", "dso", "bin" ); 638 639 'obj' has the intended object file *without* 640 extension, src2obj() is expected to add that. 641 'srcs' has the list of source files to build the 642 object file, with the first item being the source 643 file that directly corresponds to the object file. 644 'deps' is a list of explicit dependencies. 'incs' 645 is a list of include file directories. Finally, 646 'intent' indicates what this object file is going 647 to be used for. 648 649 obj2lib - function that produces build file lines to build a 650 static library file ("libfoo.a" in Unix terms) from 651 object files. 652 653 called like this: 654 655 obj2lib(lib => "PATH/TO/libfile", 656 objs => [ "PATH/TO/objectfile", ... ]); 657 658 'lib' has the intended library file name *without* 659 extension, obj2lib is expected to add that. 'objs' 660 has the list of object files (also *without* 661 extension) to build this library. 662 663 libobj2shlib - function that produces build file lines to build a 664 shareable object library file ("libfoo.so" in Unix 665 terms) from the corresponding static library file 666 or object files. 667 668 called like this: 669 670 libobj2shlib(shlib => "PATH/TO/shlibfile", 671 lib => "PATH/TO/libfile", 672 objs => [ "PATH/TO/objectfile", ... ], 673 deps => [ "PATH/TO/otherlibfile", ... ]); 674 675 'lib' has the intended library file name *without* 676 extension, libobj2shlib is expected to add that. 677 'shlib' has the corresponding shared library name 678 *without* extension. 'deps' has the list of other 679 libraries (also *without* extension) this library 680 needs to be linked with. 'objs' has the list of 681 object files (also *without* extension) to build 682 this library. 683 684 This function has a choice; it can use the 685 corresponding static library as input to make the 686 shared library, or the list of object files. 687 688 obj2dso - function that produces build file lines to build a 689 dynamic shared object file from object files. 690 691 called like this: 692 693 obj2dso(lib => "PATH/TO/libfile", 694 objs => [ "PATH/TO/objectfile", ... ], 695 deps => [ "PATH/TO/otherlibfile", 696 ... ]); 697 698 This is almost the same as libobj2shlib, but the 699 intent is to build a shareable library that can be 700 loaded in runtime (a "plugin"...). The differences 701 are subtle, one of the most visible ones is that the 702 resulting shareable library is produced from object 703 files only. 704 705 obj2bin - function that produces build file lines to build an 706 executable file from object files. 707 708 called like this: 709 710 obj2bin(bin => "PATH/TO/binfile", 711 objs => [ "PATH/TO/objectfile", ... ], 712 deps => [ "PATH/TO/libfile", ... ]); 713 714 'bin' has the intended executable file name 715 *without* extension, obj2bin is expected to add 716 that. 'objs' has the list of object files (also 717 *without* extension) to build this library. 'deps' 718 has the list of library files (also *without* 719 extension) that the programs needs to be linked 720 with. 721 722 in2script - function that produces build file lines to build a 723 script file from some input. 724 725 called like this: 726 727 in2script(script => "PATH/TO/scriptfile", 728 sources => [ "PATH/TO/infile", ... ]); 729 730 'script' has the intended script file name. 731 'sources' has the list of source files to build the 732 resulting script from. 733 734In all cases, file file paths are relative to the build tree top, and 735the build file actions run with the build tree top as current working 736directory. 737 738Make sure to end the section with these functions with a string that 739you thing is appropriate for the resulting build file. If nothing 740else, end it like this: 741 742 ""; # Make sure no lingering values end up in the Makefile 743 -} 744 745 746Configure helper scripts 747======================== 748 749Configure uses helper scripts in this directory: 750 751Checker scripts 752--------------- 753 754These scripts are per platform family, to check the integrity of the 755tools used for configuration and building. The checker script used is 756either {build_platform}-{build_file}-checker.pm or 757{build_platform}-checker.pm, where {build_platform} is the second 758'build_scheme' list element from the configuration target data, and 759{build_file} is 'build_file' from the same target data. 760 761If the check succeeds, the script is expected to end with a non-zero 762expression. If the check fails, the script can end with a zero, or 763with a `die`. 764