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
17 operations on targets according to the build specification, or build‐
18 spec for short. This process can be controlled by specifying driver
19 options 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
156 result 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
234 install modules are loaded by default. The config module is
235 always 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:
254 $ b info: libfoo/ libbar/
256 The build system has the following built-in and pre-defined operations:
258 update
260 Update a target.
261 clean
263 Clean a target.
264 test
266 Test a target. Performs update as a pre-operation. Implemented
267 by the test module.
268 update-for-test
270 Update a target for testing. This operation is equivalent to the
271 update pre-operation as executed by the test operation and can
272 be used to only update what is necessary for testing. Imple‐
273 mented by the test module.
274 install
276 Install a target. Performs update as a pre-operation. Imple‐
277 mented by the install module.
278 uninstall
280 Uninstall a target. Performs update as a pre-operation. Imple‐
281 mented by the install module.
282 update-for-install
284 Update a target for installation. This operation is equivalent
285 to the update pre-operation as executed by the install operation
286 and can be used to only update what is necessary for installa‐
287 tion. Implemented by the install module.
288 Note that buildspec and command line variable values are treated as
290 buildfile fragments and so can use quoting and escaping as well as con‐
291 tain variable expansions and evaluation contexts. However, to be more
292 usable on various platforms, escaping in these two situations is lim‐
293 ited to the effective sequences of \', \", \\, \$, and \( with all
294 other sequences interpreted as is. Together with double-quoting this is
295 sufficient to represent any value. For example:
296 $ b config.install.root=c:\projects\install
298 $ b "config.install.root='c:\Program Files (x86)\test\'"
299 $ b 'config.cxx.poptions=-DFOO_STR="foo"'
300
302 -v Print actual commands being executed. This options is equivalent
303 to --verbose 2.
304 -V Print all underlying commands being executed. This options is
306 equivalent to --verbose 3.
307 --quiet|-q
309 Run quietly, only printing error messages in most contexts. In
310 certain contexts (for example, while updating build system mod‐
311 ules) this verbosity level may be ignored. Use --silent to run
312 quietly in all contexts. This option is equivalent to --verbose
313 0.
314 --silent
316 Run quietly, only printing error messages in all contexts.
317 --verbose level
319 Set the diagnostics verbosity to level between 0 and 6. Level 0
320 disables any non-error messages (but see the difference between
321 --quiet and --silent) while level 6 produces lots of informa‐
322 tion, with level 1 being the default. The following additional
323 types of diagnostics are produced at each level:
324 1. High-level information messages.
326 2. Essential underlying commands being executed.
328 3. All underlying commands being executed.
330 4. Information that could be helpful to the user.
332 5. Information that could be helpful to the developer.
334 6. Even more detailed information.
336 --stat Display build statistics.
338 --dump phase
340 Dump the build system state after the specified phase. Valid
341 phase values are load (after loading buildfiles) and match
342 (after matching rules to targets). Repeat this option to dump
343 the state after multiple phases.
344 --progress
346 Display build progress. If printing to a terminal the progress
347 is displayed by default for low verbosity levels. Use --no-
348 progress to suppress.
349 --no-progress
351 Don't display build progress.
352 --jobs|-j num
354 Number of active jobs to perform in parallel. This includes both
355 the number of active threads inside the build system as well as
356 the number of external commands (compilers, linkers, etc)
357 started but not yet finished. If this option is not specified or
358 specified with the 0 value, then the number of available hard‐
359 ware threads is used.
360 --max-jobs|-J num
362 Maximum number of jobs (threads) to create. The default is 8x
363 the number of active jobs (--jobs|j) on 32-bit architectures and
364 32x on 64-bit. See the build system scheduler implementation for
365 details.
366 --queue-depth|-Q num
368 The queue depth as a multiplier over the number of active jobs.
369 Normally we want a deeper queue if the jobs take long (for exam‐
370 ple, compilation) and shorter if they are quick (for example,
371 simple tests). The default is 4. See the build system scheduler
372 implementation for details.
373 --max-stack num
375 The maximum stack size in KBytes to allow for newly created
376 threads. For pthreads-based systems the driver queries the stack
377 size of the main thread and uses the same size for creating
378 additional threads. This allows adjusting the stack size using
379 familiar mechanisms, such as ulimit. Sometimes, however, the
380 stack size of the main thread is excessively large. As a
381 result, the driver checks if it is greater than a predefined
382 limit (64MB on 64-bit systems and 32MB on 32-bit ones) and caps
383 it to a more sensible value (8MB) if that's the case. This
384 option allows you to override this check with the special zero
385 value indicating that the main thread stack size should be used
386 as is.
387 --serial-stop|-s
389 Run serially and stop at the first error. This mode is useful to
390 investigate build failures that are caused by build system
391 errors rather than compilation errors. Note that if you don't
392 want to keep going but still want parallel execution, add
393 --jobs|-j (for example -j 0 for default concurrency).
394 --dry-run|-n
396 Print commands without actually executing them. Note that com‐
397 mands that are required to create an accurate build state will
398 still be executed and the extracted auxiliary dependency infor‐
399 mation saved. In other words, this is not the "don't touch the
400 filesystem" mode but rather "do minimum amount of work to show
401 what needs to be done". Note also that only the perform meta-
402 operation supports this mode.
403 --match-only
405 Match the rules but do not execute the operation. This mode is
406 primarily useful for profiling.
407 --structured-result
409 Write the result of execution in a structured form. In this
410 mode, instead of printing to STDERR diagnostics messages about
411 the outcome of executing actions on targets, the driver writes
412 to STDOUT a structured result description one line per the
413 buildspec action/target pair. Each line has the following for‐
414 mat:
415 state meta-operation operation target
417 Where state can be one of unchanged, changed, or failed. If the
419 action is a pre or post operation, then the outer operation is
420 specified in parenthesis. For example:
421 unchanged perform update(test) /tmp/dir{hello/}
423 changed perform test /tmp/dir{hello/}
424 Note that only the perform meta-operation supports the struc‐
426 tured result output.
427 --mtime-check
429 Perform file modification time sanity checks. These checks can
430 be helpful in diagnosing spurious rebuilds and are enabled by
431 default for the staged version of the build system. Use --no-
432 mtime-check to disable.
433 --no-mtime-check
435 Don't perform file modification time sanity checks.
436 --no-column
438 Don't print column numbers in diagnostics.
439 --no-line
441 Don't print line and column numbers in diagnostics.
442 --buildfile path
444 The alternative file to read build information from. The default
445 is buildfile or build2file, depending on the project's build
446 file/directory naming scheme. If path is '-', then read from
447 STDIN. Note that this option only affects the files read as part
448 of the buildspec processing. Specifically, it has no effect on
449 the source and include directives. As a result, this option is
450 primarily intended for testing rather than changing the build
451 file names in real projects.
452 --config-guess path
454 The path to the config.guess(1) script that should be used to
455 guess the host machine triplet. If this option is not specified,
456 then b will fall back on to using the target it was built for as
457 host.
458 --config-sub path
460 The path to the config.sub(1) script that should be used to
461 canonicalize machine triplets. If this option is not specified,
462 then b will use its built-in canonicalization support which
463 should be sufficient for commonly-used platforms.
464 --pager path
466 The pager program to be used to show long text. Commonly used
467 pager programs are less and more. You can also specify addi‐
468 tional options that should be passed to the pager program with
469 --pager-option. If an empty string is specified as the pager
470 program, then no pager will be used. If the pager program is not
471 explicitly specified, then b will try to use less. If it is not
472 available, then no pager will be used.
473 --pager-option opt
475 Additional option to be passed to the pager program. See --pager
476 for more information on the pager program. Repeat this option to
477 specify multiple pager options.
478 --default-options dir
480 The directory to load additional default options files from.
481 --no-default-options
483 Don't load default options files.
484 --help Print usage information and exit.
486 --version
488 Print version and exit.
489
491 Instead of having a separate config file format for tool configuration,
492 the build2 toolchain uses default options files which contain the same
493 options as what can be specified on the command line. The default
494 options files are like options files that one can specify with
495 --options-file except that they are loaded by default.
496 The default options files for the build system driver are called
498 b.options and are searched for in the .build2/ subdirectory of the home
499 directory and in the system directory (for example, /etc/build2/) if
500 configured.
501 Once the search is complete, the files are loaded in the reverse order,
503 that is, beginning from the system directory (if any), followed by the
504 home directory, and finishing off with the options specified on the
505 command line. In other words, the files are loaded from the more
506 generic to the more specific with the command line options having the
507 ability to override any values specified in the default options files.
508 If a default options file contains --no-default-options, then the
510 search is stopped at the directory containing this file and no outer
511 files are loaded. If this option is specified on the command line, then
512 none of the default options files are searched for or loaded.
513 An additional directory containing default options files can be speci‐
515 fied with --default-options. Its configuration files are loaded after
516 the home directory.
517 The order in which default options files are loaded is traced at the
519 verbosity level 3 (-V option) or higher.
520
522 Non-zero exit status is returned in case of an error.
523
525 The HOME environment variable is used to determine the user's home
526 directory. If it is not set, then getpwuid(3) is used instead. This
527 value is used to shorten paths printed in diagnostics by replacing the
528 home directory with ~/. It is also made available to buildfile's as the
529 build.home variable.
530
532 Send bug reports to the users@build2.org mailing list.
533
535 Copyright (c) 2014-2020 the build2 authors.
536 Permission is granted to copy, distribute and/or modify this document
538 under the terms of the MIT License.
539build2 0.13.0 July 2020 b(1)