1b(1) General Commands Manual b(1)
2
6 b - build system driver
7
9 b --help
10 b --version
11 b [options] [variables] [buildspec]
12 buildspec = meta-operation(operation(target...[,parameters])...)...
14
16 The build2 build system driver executes a set of meta-operations on op‐
17 erations on targets according to the build specification, or buildspec
18 for short. This process can be controlled by specifying driver options
19 and build system variables.
20 Note that options, variables, and buildspec fragments can be specified
22 in any order. To avoid treating an argument that starts with '-' as an
23 option, add the '--' separator. To avoid treating an argument that con‐
24 tains '=' as a variable, add the second '--' separator.
25 All components in the buildspec can be omitted. If meta-operation is
27 omitted, then it defaults to perform. If operation is omitted, then it
28 defaults to the default operation for this meta-operation. For perform
29 it is update. Finally, if target is omitted, then it defaults to the
30 current working directory. A meta-operation on operation is called an
31 action. Some operations and meta-operations may take additional parame‐
32 ters. For example:
33 $ b # perform(update(./))
35 $ b foo/ # perform(update(foo/))
36 $ b foo/ bar/ # perform(update(foo/ bar/))
37 $ b update # perform(update(./))
38 $ b 'clean(../)' # perform(clean(../))
39 $ b perform # perform(update(./))
40 $ b configure # configure(?(./))
41 $ b 'configure(../)' # configure(?(../))
42 $ b clean update # perform(clean(./) update(./))
43 $ b configure update # configure(?(./)) perform(update(./))
44 $ b 'create(conf/, cxx)' # create(?(conf/), cxx)
45 Notice the question mark used to show the (imaginary) default operation
47 for the configure meta-operation. For configure the default operation
48 is "all operations". That is, it will configure all the operations for
49 the specified target.
50 You can also "generate" multiple operations for the same set of tar‐
52 gets. Compare:
53 $ b 'clean(foo/ bar/)' 'update(foo/ bar/)'
55 $ b '{clean update}(foo/ bar/)'
56 Some more useful buildspec examples:
58 $ b '{clean update}(...)' # rebuild
60 $ b '{clean update clean}(...)' # make sure builds
61 $ b '{clean test clean}(...)' # make sure passes tests
62 $ b '{clean disfigure}(...)' # similar to distclean
63 In POSIX shells parenthesis are special characters and must be quoted
65 when used in a buildspec. Besides being an inconvenience in itself,
66 quoting also inhibits path auto-completion. To help with this situation
67 a shortcut syntax is available for executing a single operation or
68 meta-operation, for example:
69 $ b clean: foo/ bar/ # clean(foo/ bar/)
71 $ b configure: src/@out/ # configure(src/@out/)
72 $ b create: conf/, cxx # create(conf/, cxx)
73 $ b configure: config.cxx=g++ src/ # configure(src/) config.cxx=g++
74 To activate the shortcut syntax the first buildspec argument must start
76 with an operation or meta-operation name and end with a colon (:). To
77 transform the shortcut syntax to the normal buildspec syntax the colon
78 is replaced with the opening parenthesis ('('), the rest of the build‐
79 spec arguments are treated as is, and the final closing parenthesis
80 (')') is added.
81 For each target the driver expects to find buildfile either in the tar‐
83 get's directory or, if the directory is part of the out tree
84 (out_base), in the corresponding src directory (src_base).
85 For example, assuming foo/ is the source directory of a project:
87 $ b foo/ # out_base=src_base=foo/
89 $ b foo-out/ # out_base=foo-out/ src_base=foo/
90 $ b foo-out/exe{foo} # out_base=foo-out/ src_base=foo/
91 An exception to this requirement is a directory target in which case,
93 provided the directory has subdirectories, an implied buildfile with
94 the following content is assumed:
95 # Implied directory buildfile: build all subdirectories.
97 #
98 ./: */
99 In the above example, we assumed that the build system driver was able
101 to determine the association between out_base and src_base. In case
102 src_base and out_base are not the same directory, this is achieved in
103 one of two ways: the config module (which implements the configure,
104 disfigure, and create meta-operations) saves this association as part
105 of the configuration process. If, however, the association hasn't been
106 saved, then we have to specify src_base explicitly using the following
107 extended target syntax:
108 src-base/@target
110 Continuing with the previous example:
112 $ b foo/@foo-out/exe{foo} # out_base=foo-out/ src_base=foo/
114 Normally, you would need to specify src_base explicitly only once, dur‐
116 ing configuration. For example, a typical usage would be:
117 $ b configure: foo/@foo-out/ # src_base is saved
119 $ b foo-out/ # no need to specify src_base
120 $ b clean: foo-out/exe{foo} # no need to specify src_base
121 Besides in and out of source builds, build2 also supports configuring a
123 project's source directory as forwarded to an out of source build. With
124 such a forwarded configuration in place, if we run the build system
125 driver from the source directory, it will automatically build in the
126 output directory and backlink (using symlinks or another suitable mech‐
127 anism) certain "interesting" targets (executables, documentation, etc)
128 to the source directory for easy access. Continuing with the previous
129 example:
130 $ b configure: foo/@foo-out/,forward # foo/ forwarded to foo-out/
132 $ cd foo/
133 $ b # build in foo-out/
134 $ ./foo # symlink to foo-out/foo
135 The ability to specify build2 variables as part of the command line is
137 normally used to pass configuration values, for example:
138 $ b config.cxx=clang++ config.cxx.coptions=-O3
140 Similar to buildspec, POSIX shells often inhibit path auto-completion
142 on the right hand side of a variable assignment. To help with this sit‐
143 uation the assignment can be broken down into three separate command
144 line arguments, for example:
145 $ b config.import.libhello = ../libhello/
147 The build system has the following built-in and pre-defined meta-opera‐
149 tions:
150 perform
152 Perform an operation.
153 configure
155 Configure all operations supported by a project and save the re‐
156 sult in the project's build/config.build file. Implemented by
157 the config module. For example:
158 $ b configure \
160 config.cxx=clang++ \
161 config.cxx.coptions=-O3 \
162 config.install.root=/usr/local \
163 config.install.root.sudo=sudo
164 Use the forward parameter to instead configure a source direc‐
166 tory as forwarded to an out of source build. For example:
167 $ b configure: src/@out/,forward
169 disfigure
171 Disfigure all operations supported by a project and remove the
172 project's build/config.build file. Implemented by the config
173 module.
174 Use the forward parameter to instead disfigure forwarding of a
176 source directory to an out of source build. For example:
177 $ b disfigure: src/,forward
179 create
181 Create and configure a configuration project. Implemented by the
182 config module.
183 Normally a build2 project is created manually by writing the
185 bootstrap.build and config.build files, adding source files, and
186 so on. However, a special kind of project, which we call config‐
187 uration, is often useful. Such a project doesn't have any source
188 files of its own. Instead, it serves as an amalgamation for
189 building other projects as part of it. Doing it this way has two
190 major benefits: sub-projects automatically resolve their imports
191 to other projects in the amalgamation and sub-projects inherits
192 their configuration from the amalgamation (which means if we
193 want to change something, we only need to do it in one place).
194 As an example, let's assume we have two C++ projects: the lib‐
196 hello library in libhello/ and the hello executable that imports
197 it in hello/. And we want to build hello with clang++.
198 One way to do it would be to configure and build each project in
200 its own directory, for example:
201 $ b configure: libhello/@libhello-clang/ config.cxx=clang++
203 $ b configure: hello/@hello-clang/ config.cxx=clang++ \
204 config.import.libhello=libhello-clang/
205 The two drawbacks, as mentioned above, are the need to explic‐
207 itly resolve the import and having to make changes in multiple
208 places should, for example, we want to switch from clang++ to
209 g++.
210 We can, however, achieve the same end result but without any of
212 the drawbacks using the configuration project:
213 $ b create: clang/,cxx config.cxx=clang++ # Creates clang/.
215 $ b configure: libhello/@clang/libhello/
216 $ b configure: hello/@clang/hello/
217 The targets passed to the create meta-operation must be directo‐
219 ries which should either not exist or be empty. For each such
220 directory create first initializes a project as described below
221 and then configures it by executing the configure meta-opera‐
222 tion.
223 The first optional parameter to create is the list of modules to
225 load in root.build. By default, create appends .config to the
226 names of these modules so that only their configurations are
227 loaded. You can override this behavior by specifying the period
228 (.) after the module name. You can also instruct create to use
229 the optional module load by prefixing the module name with the
230 question mark (?).
231 The second optional parameter is the list of modules to load in
233 bootstrap.build. If not specified, then the test, dist, and in‐
234 stall modules are loaded by default. The config module is always
235 loaded first.
236 Besides creating project's bootstrap.build and root.build, cre‐
238 ate also writes the root buildfile with the following contents:
239 ./: {*/ -build/}
241 If used, this buildfile will build all the sub-projects cur‐
243 rently present in the configuration.
244 dist
246 Prepare a distribution containing all files necessary to perform
247 all operations in a project. Implemented by the dist module.
248 info
250 Print basic information (name, version, source and output direc‐
251 tories, etc) about one or more projects to stdout, separating
252 multiple projects with a blank line. Each project is identified
253 by its root directory target. For example (some output is omit‐
254 ted):
255 $ b info: libfoo/ libbar/
257 project: libfoo
258 version: 1.0.0
259 src_root: /tmp/libfoo
260 out_root: /tmp/libfoo
261 subprojects: @tests
262 project: libbar
264 version: 2.0.0
265 src_root: /tmp/libbar
266 out_root: /tmp/libbar-out
267 subprojects: @tests
268 To omit discovering and printing subprojects information, use
270 the no_subprojects parameter, for example:
271 $ b info: libfoo/,no_subprojects
273 To instead print this information in the JSON format, use the
275 json parameter, for example:
276 $ b info: libfoo/,json
278 In this case the output is a JSON array of objects which are the
280 serialized representation of the following C++ struct
281 project_info:
282 struct subproject
284 {
285 string path;
286 optional<string> name;
287 };
288 struct project_info
290 {
291 optional<string> project;
292 optional<string> version;
293 optional<string> summary;
294 optional<string> url;
295 string src_root;
296 string out_root;
297 optional<string> amalgamation;
298 vector<subproject> subprojects;
299 vector<string> operations;
300 vector<string> meta_operations;
301 vector<string> modules;
302 };
303 For example:
305 [
307 {
308 "project": "libfoo",
309 "version": "1.0.0",
310 "summary": "libfoo C++ library",
311 "src_root": "/tmp/libfoo",
312 "out_root": "/tmp/gcc-debug/libfoo",
313 "amalgamation": "..",
314 "subprojects": [
315 {
316 "path": "tests"
317 }
318 ],
319 "operations": [
320 "update",
321 "clean",
322 "test",
323 "update-for-test",
324 "install",
325 "uninstall",
326 "update-for-install"
327 ],
328 "meta-operations": [
329 "perform",
330 "configure",
331 "disfigure",
332 "dist",
333 "info"
334 ],
335 "modules": [
336 "version",
337 "config",
338 "test",
339 "install",
340 "dist"
341 ]
342 }
343 ]
344 See the JSON OUTPUT section below for details on the overall
346 properties of this format and the semantics of the struct seri‐
347 alization.
348 The build system has the following built-in and pre-defined operations:
350 update
352 Update a target.
353 clean
355 Clean a target.
356 test
358 Test a target. Performs update as a pre-operation. Implemented
359 by the test module.
360 update-for-test
362 Update a target for testing. This operation is equivalent to the
363 update pre-operation as executed by the test operation and can
364 be used to only update what is necessary for testing. Imple‐
365 mented by the test module.
366 install
368 Install a target. Performs update as a pre-operation. Imple‐
369 mented by the install module.
370 uninstall
372 Uninstall a target. Performs update as a pre-operation. Imple‐
373 mented by the install module.
374 update-for-install
376 Update a target for installation. This operation is equivalent
377 to the update pre-operation as executed by the install operation
378 and can be used to only update what is necessary for installa‐
379 tion. Implemented by the install module.
380 Note that buildspec and command line variable values are treated as
382 buildfile fragments and so can use quoting and escaping as well as con‐
383 tain variable expansions and evaluation contexts. However, to be more
384 usable on various platforms, escaping in these two situations is lim‐
385 ited to the effective sequences of \', \", \\, \$, and \( with all
386 other sequences interpreted as is. Together with double-quoting this is
387 sufficient to represent any value. For example:
388 $ b config.install.root=c:\projects\install
390 $ b "config.install.root='c:\Program Files\test\'"
391 $ b 'config.cxx.poptions=-DFOO_STR="foo"'
392
394 -v Print actual commands being executed. This options is equivalent
395 to --verbose 2.
396 -V Print all underlying commands being executed. This options is
398 equivalent to --verbose 3.
399 --quiet|-q
401 Run quietly, only printing error messages in most contexts. In
402 certain contexts (for example, while updating build system mod‐
403 ules) this verbosity level may be ignored. Use --silent to run
404 quietly in all contexts. This option is equivalent to --verbose
405 0.
406 --silent
408 Run quietly, only printing error messages in all contexts.
409 --verbose level
411 Set the diagnostics verbosity to level between 0 and 6. Level 0
412 disables any non-error messages (but see the difference between
413 --quiet and --silent) while level 6 produces lots of informa‐
414 tion, with level 1 being the default. The following additional
415 types of diagnostics are produced at each level:
416 1. High-level information messages.
418 2. Essential underlying commands being executed.
420 3. All underlying commands being executed.
422 4. Information that could be helpful to the user.
424 5. Information that could be helpful to the developer.
426 6. Even more detailed information.
428 --stat Display build statistics.
430 --progress
432 Display build progress. If printing to a terminal the progress
433 is displayed by default for low verbosity levels. Use --no-
434 progress to suppress.
435 --no-progress
437 Don't display build progress.
438 --diag-color
440 Use color in diagnostics. If printing to a terminal the color is
441 used by default provided the terminal is not dumb. Use --no-
442 diag-color to suppress.
443 This option affects the diagnostics printed by the build system
445 itself. Some rules may also choose to propagate its value to
446 tools (such as compilers) that they invoke.
447 --no-diag-color
449 Don't use color in diagnostics.
450 --jobs|-j num
452 Number of active jobs to perform in parallel. This includes both
453 the number of active threads inside the build system as well as
454 the number of external commands (compilers, linkers, etc)
455 started but not yet finished. If this option is not specified or
456 specified with the 0 value, then the number of available hard‐
457 ware threads is used.
458 --max-jobs|-J num
460 Maximum number of jobs (threads) to create. The default is 8x
461 the number of active jobs (--jobs|j) on 32-bit architectures and
462 32x on 64-bit. See the build system scheduler implementation for
463 details.
464 --queue-depth|-Q num
466 The queue depth as a multiplier over the number of active jobs.
467 Normally we want a deeper queue if the jobs take long (for exam‐
468 ple, compilation) and shorter if they are quick (for example,
469 simple tests). The default is 4. See the build system scheduler
470 implementation for details.
471 --file-cache impl
473 File cache implementation to use for intermediate build results.
474 Valid values are noop (no caching or compression) and sync-lz4
475 (no caching with synchronous LZ4 on-disk compression). If this
476 option is not specified, then a suitable default implementation
477 is used (currently sync-lz4).
478 --max-stack num
480 The maximum stack size in KBytes to allow for newly created
481 threads. For pthreads-based systems the driver queries the stack
482 size of the main thread and uses the same size for creating ad‐
483 ditional threads. This allows adjusting the stack size using fa‐
484 miliar mechanisms, such as ulimit. Sometimes, however, the
485 stack size of the main thread is excessively large. As a re‐
486 sult, the driver checks if it is greater than a predefined limit
487 (64MB on 64-bit systems and 32MB on 32-bit ones) and caps it to
488 a more sensible value (8MB) if that's the case. This option al‐
489 lows you to override this check with the special zero value in‐
490 dicating that the main thread stack size should be used as is.
491 --serial-stop|-s
493 Run serially and stop at the first error. This mode is useful to
494 investigate build failures that are caused by build system er‐
495 rors rather than compilation errors. Note that if you don't want
496 to keep going but still want parallel execution, add --jobs|-j
497 (for example -j 0 for default concurrency). Note also that dur‐
498 ing serial execution there is no diagnostics buffering and child
499 process' stderr is a terminal (unless redirected; see --no-diag-
500 buffer for details).
501 --dry-run|-n
503 Print commands without actually executing them. Note that com‐
504 mands that are required to create an accurate build state will
505 still be executed and the extracted auxiliary dependency infor‐
506 mation saved. In other words, this is not the "don't touch the
507 filesystem" mode but rather "do minimum amount of work to show
508 what needs to be done". Note also that only the perform meta-op‐
509 eration supports this mode.
510 --no-diag-buffer
512 Do not buffer diagnostics from child processes. By default, un‐
513 less running serially, such diagnostics is buffered and printed
514 all at once after each child exits in order to prevent inter‐
515 leaving. However, this can have side-effects since the child
516 process' stderr is no longer a terminal. Most notably, the use
517 of color in diagnostics may be disabled by some programs. On the
518 other hand, depending on the platform and programs invoked, the
519 interleaving diagnostics may not break lines and thus could be
520 tolerable.
521 --match-only
523 Match the rules without executing the operation. This mode is
524 primarily useful for profiling and dumping the build system
525 state.
526 --load-only
528 Match the rules only to alias{} targets ignoring other targets
529 and without executing the operation. In particular, this has the
530 effect of loading all the subdirectory buildfiles that are not
531 explicitly included. Note that this option can only be used with
532 the perform(update) action on an alias{} target, usually dir{}.
533 --no-external-modules
535 Don't load external modules during project bootstrap. Note that
536 this option can only be used with meta-operations that do not
537 load the project's buildfiles, such as info.
538 --structured-result fmt
540 Write the result of execution in a structured form. In this
541 mode, instead of printing to stderr diagnostics messages about
542 the outcome of executing actions on targets, the driver writes
543 to stdout a machine-readable result description in the specified
544 format. Valid values for this option are lines and json. Note
545 that currently only the perform meta-operation supports the
546 structured result output.
547 If the output format is lines, then the result is written one
549 line per the buildspec action/target pair. Each line has the
550 following form:
551 state meta-operation operation target
553 Where state can be one of unchanged, changed, or failed. If the
555 action is a pre or post operation, then the outer operation is
556 specified in parenthesis. For example:
557 unchanged perform update(test) /tmp/hello/hello/exe{hello}
559 changed perform test /tmp/hello/hello/exe{hello}
560 If the output format is json, then the output is a JSON array of
562 objects which are the serialized representation of the following
563 C++ struct target_action_result:
564 struct target_action_result
566 {
567 string target;
568 string display_target;
569 string target_type;
570 optional<string> target_path;
571 string meta_operation;
572 string operation;
573 optional<string> outer_operation;
574 string state;
575 };
576 For example:
578 [
580 {
581 "target": "/tmp/hello/hello/exe{hello.}",
582 "display_target": "/tmp/hello/hello/exe{hello}",
583 "target_type": "exe",
584 "target_path": "/tmp/hello/hello/hello",
585 "meta_operation": "perform",
586 "operation": "update",
587 "outer_operation": "test",
588 "state": "unchanged"
589 },
590 {
591 "target": "/tmp/hello/hello/exe{hello.}",
592 "display_target": "/tmp/hello/hello/exe{hello}",
593 "target_type": "exe",
594 "target_path": "/tmp/hello/hello/hello",
595 "meta_operation": "perform",
596 "operation": "test",
597 "state": "changed"
598 }
599 ]
600 See the JSON OUTPUT section below for details on the overall
602 properties of this format and the semantics of the struct seri‐
603 alization.
604 The target member is the target name that is qualified with the
606 extension (if applicable) and, if required, is quoted so that it
607 can be passed back to the build system driver on the command
608 line. The display_target member is the unqualified and unquoted
609 "display" target name, the same as in the lines format. The tar‐
610 get_type member is the type of target. The target_path member
611 is an absolute path to the target if the target type is path-
612 based or dir.
613 --mtime-check
615 Perform file modification time sanity checks. These checks can
616 be helpful in diagnosing spurious rebuilds and are enabled by
617 default on Windows (which is known not to guarantee monotoni‐
618 cally increasing mtimes) and for the staged version of the build
619 system on other platforms. Use --no-mtime-check to disable.
620 --no-mtime-check
622 Don't perform file modification time sanity checks. See --mtime-
623 check for details.
624 --dump phase
626 Dump the build system state after the specified phase. Valid
627 phase values are load (after loading buildfiles) and match (af‐
628 ter matching rules to targets). The match value also has the
629 match-pre and match-post variants to dump the state for the
630 pre/post-operations (match dumps the main operation only). Re‐
631 peat this option to dump the state after multiple phases/vari‐
632 ants. By default the entire build state is dumped but this be‐
633 havior can be altered with the --dump-scope and --dump-target
634 options. See also the --match-only and --load-only options.
635 --dump-format format
637 Representation format and output stream to use when dumping the
638 build system state. Valid values for this option are buildfile
639 (a human-readable, Buildfile-like format written to stderr; this
640 is the default), and json-v0.1 (machine-readable, JSON-based
641 format written to stdout). For details on the buildfile format,
642 see Diagnostics and Debugging (#intro-diag-debug). For details
643 on the json-v0.1 format, see the JSON OUTPUT section below
644 (overall properties) and JSON Dump Format (#json-dump) (format
645 specifics). Note that the JSON format is currently unstable
646 (thus the temporary -v0.1 suffix).
647 Note that because it's possible to end up with multiple dumps
649 (for example, by specifying the --dump-scope and/or --dump-tar‐
650 get options multiple times), the JSON output is in the "JSON
651 Lines" form, that is, without pretty-printing and with the top-
652 level JSON objects delimited by newlines. Note also that if the
653 JSON dump output is combined with --structured-result=json, then
654 the structured result is the last line.
655 --dump-scope dir
657 Dump the build system state for the specified scope only. Repeat
658 this option to dump the state of multiple scopes.
659 --dump-target target
661 Dump the build system state for the specified target only. Re‐
662 peat this option to dump the state of multiple targets.
663 --trace-match target
665 Trace rule matching for the specified target. This is primarily
666 useful during troubleshooting. Repeat this option to trace mul‐
667 tiple targets.
668 --trace-execute target
670 Trace rule execution for the specified target. This is primarily
671 useful during troubleshooting. Repeat this option to trace mul‐
672 tiple targets.
673 --no-column
675 Don't print column numbers in diagnostics.
676 --no-line
678 Don't print line and column numbers in diagnostics.
679 --buildfile path
681 The alternative file to read build information from. The default
682 is buildfile or build2file, depending on the project's build
683 file/directory naming scheme. If path is '-', then read from
684 stdin. Note that this option only affects the files read as part
685 of the buildspec processing. Specifically, it has no effect on
686 the source and include directives. As a result, this option is
687 primarily intended for testing rather than changing the build
688 file names in real projects.
689 --config-guess path
691 The path to the config.guess(1) script that should be used to
692 guess the host machine triplet. If this option is not specified,
693 then b will fall back on to using the target it was built for as
694 host.
695 --config-sub path
697 The path to the config.sub(1) script that should be used to
698 canonicalize machine triplets. If this option is not specified,
699 then b will use its built-in canonicalization support which
700 should be sufficient for commonly-used platforms.
701 --pager path
703 The pager program to be used to show long text. Commonly used
704 pager programs are less and more. You can also specify addi‐
705 tional options that should be passed to the pager program with
706 --pager-option. If an empty string is specified as the pager
707 program, then no pager will be used. If the pager program is not
708 explicitly specified, then b will try to use less. If it is not
709 available, then no pager will be used.
710 --pager-option opt
712 Additional option to be passed to the pager program. See --pager
713 for more information on the pager program. Repeat this option to
714 specify multiple pager options.
715 --options-file file
717 Read additional options from file. Each option should appear on
718 a separate line optionally followed by space or equal sign (=)
719 and an option value. Empty lines and lines starting with # are
720 ignored. Option values can be enclosed in double (") or single
721 (') quotes to preserve leading and trailing whitespaces as well
722 as to specify empty values. If the value itself contains trail‐
723 ing or leading quotes, enclose it with an extra pair of quotes,
724 for example '"x"'. Non-leading and non-trailing quotes are in‐
725 terpreted as being part of the option value.
726 The semantics of providing options in a file is equivalent to
728 providing the same set of options in the same order on the com‐
729 mand line at the point where the --options-file option is speci‐
730 fied except that the shell escaping and quoting is not required.
731 Repeat this option to specify more than one options file.
732 --default-options dir
734 The directory to load additional default options files from.
735 --no-default-options
737 Don't load default options files.
738 --help Print usage information and exit.
740 --version
742 Print version and exit.
743
745 Instead of having a separate config file format for tool configuration,
746 the build2 toolchain uses default options files which contain the same
747 options as what can be specified on the command line. The default op‐
748 tions files are like options files that one can specify with --options-
749 file except that they are loaded by default.
750 The default options files for the build system driver are called b.op‐
752 tions and are searched for in the .build2/ subdirectory of the home di‐
753 rectory and in the system directory (for example, /etc/build2/) if con‐
754 figured. Note that besides options these files can also contain global
755 variable overrides.
756 Once the search is complete, the files are loaded in the reverse order,
758 that is, beginning from the system directory (if any), followed by the
759 home directory, and finishing off with the options specified on the
760 command line. In other words, the files are loaded from the more
761 generic to the more specific with the command line options having the
762 ability to override any values specified in the default options files.
763 If a default options file contains --no-default-options, then the
765 search is stopped at the directory containing this file and no outer
766 files are loaded. If this option is specified on the command line, then
767 none of the default options files are searched for or loaded.
768 An additional directory containing default options files can be speci‐
770 fied with --default-options. Its configuration files are loaded after
771 the home directory.
772 The order in which default options files are loaded is traced at the
774 verbosity level 3 (-V option) or higher.
775
777 Commands that support the JSON output specify their formats as a seri‐
778 alized representation of a C++ struct or an array thereof. For example:
779 struct package
781 {
782 string name;
783 };
784 struct configuration
786 {
787 uint64_t id;
788 string path;
789 optional<string> name;
790 bool default;
791 vector<package> packages;
792 };
793 An example of the serialized JSON representation of struct configura‐
795 tion:
796 {
798 "id": 1,
799 "path": "/tmp/hello-gcc",
800 "name": "gcc",
801 "default": true,
802 "packages": [
803 {
804 "name": "hello"
805 }
806 ]
807 }
808 This sections provides details on the overall properties of such for‐
810 mats and the semantics of the struct serialization.
811 The order of members in a JSON object is fixed as specified in the cor‐
813 responding struct. While new members may be added in the future (and
814 should be ignored by older consumers), the semantics of the existing
815 members (including whether the top-level entry is an object or array)
816 may not change.
817 An object member is required unless its type is optional<>, bool, or
819 vector<> (array). For bool members absent means false. For vector<>
820 members absent means empty. An empty top-level array is always present.
821 For example, the following JSON text is a possible serialization of the
823 above struct configuration:
824 {
826 "id": 1,
827 "path": "/tmp/hello-gcc"
828 }
829
831 Non-zero exit status is returned in case of an error.
832
834 The HOME environment variable is used to determine the user's home di‐
835 rectory. If it is not set, then getpwuid(3) is used instead. This value
836 is used to shorten paths printed in diagnostics by replacing the home
837 directory with ~/. It is also made available to buildfile's as the
838 build.home variable.
839 The BUILD2_VAR_OVR environment variable is used to propagate global
841 variable overrides to nested build system driver invocations. Its value
842 is a list of global variable assignments separated with newlines.
843 The BUILD2_DEF_OPT environment variable is used to suppress loading of
845 default options files in nested build system driver invocations. Its
846 values are false or 0 to suppress and true or 1 to load.
847
849 Send bug reports to the users@build2.org mailing list.
850
852 Copyright (c) 2014-2023 the build2 authors.
853 Permission is granted to copy, distribute and/or modify this document
855 under the terms of the MIT License.
856build2 0.16.0 June 2023 b(1)