Version 0.15.0 * Support for dynamic dependencies in ad hoc recipes. Specifically, the `depdb` builtin now has the new `dyndep` command that can be used to extract dynamic dependencies from program output or a file. For example, from program output: obje{hello.o}: cxx{hello} {{ s = $path($<[0]) o = $path($>) poptions = $cxx.poptions $cc.poptions coptions = $cc.coptions $cxx.coptions depdb dyndep $poptions --what=header --default-type=h -- \ $cxx.path $poptions $coptions $cxx.mode -M -MG $s diag c++ ($<[0]) $cxx.path $poptions $coptions $cxx.mode -o $o -c $s }} Or, alternatively, from a file: t = $(o).t depdb dyndep $poptions --what=header --default-type=h --file $t -- \ $cxx.path $poptions $coptions $cxx.mode -M -MG $s >$t The above depdb-dyndep commands will run the C++ compiler with the -M -MG options to extract the header dependency information, parse the resulting make dependency declaration (either from stdout or from file) and enter each header as a prerequisite of the obje{hello.o} target, as if they were listed explicitly. It will also save this list of headers in the auxiliary dependency database (hello.o.d file) in order to detect changes to these headers on subsequent updates. The --what option specifies what to call the dependencies being extracted in diagnostics. The --default-type option specifies the default target type to use for a dependency if its file name cannot be mapped to a target type. The above depdb-dyndep variant extracts the dependencies ahead of the compilation proper and will handle auto-generated headers (see the -MG option for details) provided we pass the header search paths where they could be generated with the -I options (passed as $poptions in the above example). If there can be no auto-generated dependencies or if they can all be listed explicitly as static prerequisites, then we can use a variant of the depdb-dyndep command that extracts the dependencies as a by-product of compilation. In this mode only the --file input is supported. For example (assuming hxx{config} is auto-generated): obje{hello.o}: cxx{hello} hxx{config} {{ s = $path($<[0]) o = $path($>) t = $(o).t poptions = $cxx.poptions $cc.poptions coptions = $cc.coptions $cxx.coptions depdb dyndep --byproduct --what=header --default-type=h --file $t diag c++ ($<[0]) $cxx.path $poptions $coptions $cxx.mode -MD -MF $t -o $o -c $s }} Other options supported by the depdb-dyndep command: --format Dependency format. Currently only the `make` dependency format is supported and is the default. --cwd Working directory used to complete relative dependency paths. This option is currently only valid in the --byproduct mode (in the normal mode relative paths indicate non-existent files). --drop-cycles Drop prerequisites that are also targets. Only use this option if you are sure such cycles are harmless, that is, the output is not affected by such prerequisites' content. --update-{include,exclude} | Prerequisite targets/patterns to include/exclude (from the static prerequisite set) for update during match (those excluded will be updated during execute). The order in which these options are specified is significant with the first target/pattern that matches determining the result. If only the --update-include options are specified, then only the explicitly included prerequisites will be updated. Otherwise, all prerequisites that are not explicitly excluded will be updated. If none of these options is specified, then all the static prerequisites are updated during match. Note also that these options do not apply to ad hoc prerequisites which are always updated during match. The common use-case for the --update-exclude option is to omit updating a library which is only needed to extract exported preprocessor options. Here is a typical pattern: import libs = libhello%lib{hello} libue{hello-meta}: $libs obje{hello.o}: cxx{hello} libue{hello-meta} {{ s = $path($<[0]) o = $path($>) poptions = $cxx.poptions $cc.poptions poptions += $cxx.lib_poptions(libue{hello-meta}, obje) coptions = $cc.coptions $cxx.coptions depdb dyndep $poptions --what=header --default-type=h \ --update-exclude libue{hello-meta} -- \ $cxx.path $poptions $coptions $cxx.mode -M -MG $s diag c++ ($<[0]) $cxx.path $poptions $coptions $cxx.mode -o $o -c $s }} Version 0.14.0 * Support for hermetic build configurations. Hermetic build configurations save environment variables that affect the project along with other project configuration in the config.build file. These saved environment variables are then used instead of the current environment when performing operations on the project, thus making sure the project "sees" exactly the same environment as during configuration. The built-in ~host and ~build2 configurations are now hermetic. Hermetic configuration support is built on top of the lower-level config.config.environment configuration variable which allows us to save a custom set of environment variables/values. As part of this work we now also track changes to the environment in non- hermetic configurations and automatically rebuild affected targets. See "Hermetic Build Configurations" in the manual for details. * Support for ad hoc regex pattern rules. An ad hoc pattern rule consists of a pattern that mimics a dependency declaration followed by one or more recipes. For example: exe{~'/(.*)/'}: cxx{~'/\1/'} {{ $cxx.path -o $path($>) $path($<[0]) }} If a pattern matches a dependency declaration of a target, then the recipe is used to perform the corresponding operation on this target. For example, the following dependency declaration matches the above pattern which means the rule's recipe will be used to update this target: exe{hello}: cxx{hello} While the following declarations do not match the above pattern: exe{hello}: c{hello} # Type mismatch. exe{hello}: cxx{howdy} # Name mismatch. On the left hand side of `:` in the pattern we can have a single target or an ad hoc target group. The single target or the first (primary) ad hoc group member must be a regex pattern (~). The rest of the ad hoc group members can be patterns or substitutions (^). For example: : cxx{~'/\1/'} {{ $cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0]) }} On the right hand side of `:` in the pattern we have prerequisites which can be patterns, substitutions, or non-patterns. For example: : cxx{~'/\1/'} hxx{^'/\1/'} hxx{common} {{ $cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0]) }} Substitutions on the left hand side of `:` and substitutions and non- patterns on the right hand side are added to the dependency declaration. For example, given the above rule and dependency declaration, the effective dependency is going to be: : cxx{hello} hxx{hello} hxx{common} Similar to ad hoc recipes, ad hoc rules can be written in Buildscript or C++. * Support for regex patterns in target type/pattern-specific variables. This is in addition to the already supported path patterns. For example: hxx{*}: x = y # path pattern hxx{~/.*/}: x = y # regex pattern * New pre-defined semantics for the config..develop variable. This variable allows a project to distinguish between development and consumption builds. While normally there is no distinction, sometimes a project may need to provide additional functionality during development. For example, a source code generator which uses its own generated code in its implementation may need to provide a bootstrap step from the pre- generated code. Normally, such a step is only needed during development. If used, this variable should be explicitly defined by the project with the bool type and the false default value. For example: config [bool] config.hello.develop ?= false See "Project Configuration" in the manual for details. * Support for warning suppression from external C/C++ libraries. This is implemented by defining a notion of a project's internal scope and automatically translating header search path options (-I) exported by libraries that are outside of the internal scope to appropriate "external header search path" options (-isystem for GCC/Clang, /external:I for MSVC 16.10 and later). In the future this functionality will be extended to side-building BMIs for external module interfaces and header units. Note that this functionality is not without limitations and drawbacks and, if needed, should be enabled explicitly. See the "Compilation Internal Scope" section in the manual for details. * C++20 modules support in GCC 11 using the module mapper. This support covers all the major C++20 modules features including named modules, module partitions (both interface and implementation), header unit importation, and include translation. All of these features are also supported in libraries, including consumption of installed libraries with information about modules and importable headers conveyed in pkg-config files. Module interface-only libraries are also supported. Note that one area that is not yet well supported (due to module mapper limitations) is auto-generated headers. Also note that as of version 11, support for modules in GCC is still experimental and incomplete. * Support for automatic DLL symbol exporting. It is now possible to automatically generate a .def file that exports all symbols from a Windows DLL. See "Automatic DLL Symbol Exporting" in the manual for details. * Initial Emscripten compiler support. - Target: wasm32-emscripten (wasm32-unknown-emscripten). - Compiler id: clang-emscripten (type clang, variant emscripten, class gcc). - Ability to build executables (.js plus .wasm) and static libraries (.a). Set executable bit on the .js file (so it can be executed with a suitable binfmt interpreter). Track the additional .worker.js file if -pthread is specified. - Default config.bin.lib for wasm32-emscripten is static instead of both. - Full C++ exception support is enabled by default unless disabled explicitly by the user with -s DISABLE_EXCEPTION_CATCHING=1|2. - The bin module registers the wasm{} target type for wasm32-emscripten. * New string functions: $string.trim(), $string.lcase(), $string.ucase(). * Support for test runners (config.test.runner). Support for test timeouts (config.test.timeout). See "test Module" in the manual for details. * New install directory substitution in addition to . New config.install.etc variable with the data_root/etc/ default. See the "install Module" chapter in the manual for details. * Support for fallback substitution in the in module (in.null variable). See "in Module" in the manual for details. * New export pseudo-builtin that allows adding/removing variables to/from the current scope's commands execution environment. See the Testscript manual for details. * New ad hoc recipe depdb preamble. The Buildscript language now provides a new pseudo-builtin, depdb, that allows tracking of custom auxiliary dependency information. Invocations of this builtin should come before any recipe commands and are collectively called the depdb preamble. Non-pure functions can now only be called as part of this preamble. For example: file{output}: file{input} $foo {{ diag foo $> depdb env FOO # foo uses the FOO environment variable $foo $path($<[0]) >$path($>) }} * New ${c,cxx}.deduplicate_export_libs() functions. These functions deduplicate interface library dependencies by removing libraries that are also interface dependencies of other libraries on the specified list. This can lead to a significantly better build performance for heavily interface-interdependent library families (for example, like Boost). Typical usage: import intf_libs = ... import intf_libs += ... ... import intf_libs += ... intf_libs = $cxx.deduplicate_export_libs($intf_libs) * New ${c,cxx}.find_system_{header,library}() functions. These functions can be used to detect the presence of a header/library in one of the system header/library search directories. * New ${c,cxx}.lib_{poptions,libs,rpaths}() and $cxx.obj_modules() functions. These functions can be used to query library metadata for options and libraries that should be used when compiling/linking dependent targets, similar to how cc::{compile,link}_rule do it. With this support it should be possible to more or less re-create their semantics in ad hoc recipes. * Support for suppressing duplicates when extracting library options and linking libraries in cc::{compile,link}_rule. * The cxx.std=latest value has been mapped to c++2b for Clang 13 or later and to /std:c++20 for MSVC 16.11 or later. * Support for LTO parallelization during linking in GCC and Clang. GCC >= 10 and Clang >= 4 support controlling the number of LTO threads used during linking. The cc::link_rule now uses the build system scheduler to automatically allocate up to the number of available threads to the GCC or Clang linker processes when -flto=auto or -flto=thin is specified, respectively. * /Zc:__cplusplus is now passed by default starting from MSVC 15.7. This can be overridden by passing a variant of this option as part of the compiler mode options. * Support for disabling clean through target-prerequisite relationships. The current semantics is to clean any prerequisites that are in the same project (root scope) as the target and it may seem more natural to rather only clean prerequisites that are in the same base scope. While it's often true for simple projects, in more complex cases it's not unusual to have common intermediate build results (object files, utility libraries, etc) residing in the parent and/or sibling directories. With such arrangements, cleaning only in base may leave such intermediate build results laying around since there is no reason to list them as prerequisites of any directory aliases. So we clean in the root scope by default but now any target-prerequisite relationship can be marked not to trigger a clean with the clean=false prerequisite-specific value. For example: man1{cli}: exe{cli}: clean = false # Don't clean the man generation tool. * exe{} targets are no longer installed through target-prerequisite relationships of file-based targets. Normally, an exe{} that is listed as a prerequisite of a file-based target is there to be executed (for example, to generate that target) and not to trigger its installation (such an exe{} would typically be installed via the ./ alias). This default behavior, however, can be overridden with the install=true prerequisite-specific value. For example: exe{foo}: exe{bar}: install = true # foo runs bar * Consistently install prerequisites from any scope by default. It is also now possible to adjust this behavior with the global !config.install.scope override. Valid values for this variable are: project -- only from project bundle -- from bundle amalgamation strong -- from strong amalgamation weak -- from weak amalgamation global -- from all projects (default) * Variable names/components that start with underscore as well as variables in the build, import, and export namespaces are now reserved by the build system core. For example: _x = 1 # error x._y = 1 # error build.x = 1 # error * New int64 (signed 64-bit integer) and int64s (vector of such integers) variable types. * Default options files can now contain global variable overrides. * Support for multiple -e options (scripts) in the sed builtin. * The bin.lib.version variable no longer needs to include leading `@` for platform-independent versions. * The actualize mode of $path.normalize() is now provided by a separate $path.actualize() function. * New --options-file build system driver option that allows specifying additional options in a file. * New notion of bundle amalgamation which is defined as the outermost named strong (source-based) amalgamation. * Support for unseparated scope-qualified variable assignment and expansion. For example, now the following: foo/x = y info $(foo/x) Is equivalent to: foo/ x = y info $(foo/ x) While this makes scope-qualified syntax consistent with target-qualified, it also means that variable names that contain directory separators are now effectively reserved. * New bootstrap distribution mode (!config.dist.bootstrap=true). In this mode the dist meta-operation does not load the project (but does bootstrap it) and adds all the source files into the distribution only ignoring files and directories that start with a dot. This mode is primarily meant for situations where the project cannot (yet) be loaded due to missing dependencies. * Support for external build system modules that require bootstrap (that is, loaded in bootstrap.build). See also the new --no-external-modules option. * New file cache for intermediate build results. The file cache is used to store intermediate build results, for example, partially-preprocessed C/C++ translation units (those .i/.ii files). The cache implementation to use is controlled by the new --file-cache option. Its valid values are noop (no caching or compression) and sync-lz4 (no caching with synchronous LZ4 on-disk compression; this is the default). * New BUILD2_DEF_OPT environment variable that can be used to suppress loading of default options files. * New BUILD2_DEF_OVR environment variable that can be used to propagate global variable overrides to nested build system invocations. Version 0.13.0 * Support for project-specific configuration. A project can now use the config directive to define config..* variables, similar to the build system core and modules. For example: config [bool] config.libhello.fancy ?= false config [string] config.libhello.greeting ?= 'Hello' These variables can then be used in buildfiles and/or propagated to the source code using the command line, .in file substitution, etc. For example: if $config.libhello.fancy cxx.poptions += -DLIBHELLO_FANCY cxx.poptions += "-DLIBHELLO_GREETING=\"$config.libhello.greeting\"" See the "Project Configuration" chapter in the manual for details. * Support for ad hoc recipes. With ad hoc recipes it is now possible to provide custom implementations of operations (update, test, etc) for certain targets. For example, this is how we can pick a config header based on the platform: hxx{config}: hxx{config-linux}: include = ($cxx.target.class == 'linux') hxx{config}: hxx{config-win32}: include = ($cxx.target.class == 'windows') hxx{config}: hxx{config-macos}: include = ($cxx.target.class == 'macos') hxx{config}: {{ cp $path($<) $path($>) }} Another, more elaborate example that shows how to embed binary data into the source code with the help of the xxd(1) utility: import! xxd = xxd%exe{xxd} <{hxx cxx}{foo}>: file{foo.bin} $xxd {{ diag xxd ($<[0]) i = $path($<[0]) # Input. h = $path($>[0]) # Output header. s = $path($>[1]) # Output source. n = $name($<[0]) # Array name. # Get the position of the last byte (in hex). # $xxd -s -1 -l 1 $i | sed -n -e 's/^([0-9]+):.*$/\1/p' - | set pos if ($empty($pos)) exit "unable to extract input size from xxd output" end # Write header and source. # echo "#pragma once" >$h echo "extern const char $n[0x$pos + 1];" >>$h echo "extern const char $n[0x$pos + 1]= {" >$s $xxd -i <$i >>$s echo '};' >>$s }} Note that in both examples, the utilities (cp, echo, and sed) are builtins which means these recipes are portable. See the Testscript manual for the list of available builtins. Ad hoc recipes can also be used to customize a part of the update chain otherwise handled by rules. For example, in embedded systems development it is often required to perform a custom link step: obje{foo}: cxx{foo} obje{bar}: cxx{bar} : obje{foo bar} {{ diag ld ($>[0]) $cxx.path $cc.loptions $cxx.loptions $cxx.mode -o $path($>[0]) \ "-Wl,-Map=$path($>[1])" $path($<) $cxx.libs $cc.libs }} While the above examples are all for the update operation, ad hoc recipes can be used for other operations, such as test. For example: exe{hello}: cxx{hello} % test {{ diag test $> $> 'World' >>>?'Hello, World!' }} The above recipes are written in a shell-like language called Buildscript that has similar semantics to Testscript tests. Another language that can be used to write recipes is C++. For example: ./: {{ c++ 1 recipe apply (action, target& t) const override { text (recipe_loc) << "Hello, " << t; return noop_recipe; } }} Note that in this release support for ad hoc recipes is at the "technology preview" stage. In particular, there is no documentation and there might be some rough edges. * Support for project-local importation. An import without a project name is now treated as importation from the same project. For example, given the libhello project that exports the lib{hello} target, a buildfile for an executable in the same project instead of doing something like this: include ../libhello/ exe{hello}: ../libhello/lib{hello} Can now do: import lib = lib{hello} exe{hello}: $lib Note that the target in project-local importation must still be exported in the project's export stub. In other words, project-local importation goes through the same mechanism as normal import. See the "Target Importation" section in the manual for details. * Support for ad hoc importation and "glue buildfiles". If the target being imported has no project name and is either absolute or is a relative directory, then this is treated as ad hoc importation. Semantically it is similar to normal importation but with the location of the project being imported hard-coded into the buildfile. In particular, this type of import can be used to create a special "glue buildfile" that "pulls" together several projects, usually for convenience of development. One typical case that calls for such a glue buildfile is a multi-package project. To be able to invoke the build system directly in the project root, we can add a glue buildfile that imports and builds all the packages: import pkgs = */ ./: $pkgs See the "Target Importation" section in the manual for details. * Support for value subscripts. A value subscript is only recognized in evaluation contexts (due to ambiguity with wildcard patterns; consider: $x[123].txt) and should be unseparated from the previous token. For example: x = ($y[1]) x = (($f ? $y : $z)[1]) x = ($identity($y)[$z]) * New legal{} target type and config.install.legal variable. This allows separation of legal files (LICENSE, AUTHORS, etc) from other documentation. For example: ./: ... doc{README} legal{LICENSE} $ b install ... config.install.legal='share/licenses//' * Support for -substitutions in config.install.* values. The currently recognized variable names are and which are replaced with the project name and private subdirectory, respectively. This can be used along these lines: $ b config.install.libexec='exec_root/lib//' install The private installation subdirectory can be used to hide the implementation details of a project. This is primarily useful when installing an executable that depends on a bunch of libraries into a shared location, such as /usr/local/. For example: $ b config.install.private=foo install See the "install Module" chapter in the manual for details. * New $regex.find_{match,search}() functions that operate on lists. * The $process.run*() functions now recognize a number of portable builtins. Refer to the Testscript manual for the list and details. * New $defined() and $visibility() functions. * New $target.process_path() function for exe{} targets analogous to $target.path(). * New $bin.link_member() function. Given a linker output target type (exe, lib[as], or libu[eas]) this function returns the target type of the lib{} group member (liba or libs) that will be picked when linking a lib{} group to this target type. * New scripting builtins: date, env. Refer to the Testscript manual for details. * New variable block applicability semantics in dependency chains. Previously the block used to apply to the set of prerequisites before the last colon. This turned out to be counterintuitive and not very useful since prerequisite-specific variables are less common than target- specific ones. The new rule is as follows: if the chain ends with a colon, then the block applies to the last set of prerequisites. Otherwise, it applies to the last set of targets. For example: ./: exe{test}: cxx{main} { test = true # Applies to the exe{test} target. } ./: exe{test}: libue{test}: { bin.whole = false # Applies to the libue{test} prerequisite. } * Test and install modules are now implicitly loaded for simple projects. While these can be useful on their own, this also makes the test and install operations available in simple projects, which is handy for "glue buildfiles" that "pull" (using ad hoc import) a bunch of other projects together. * The translated {c,cxx}.std options are now folded into the compiler mode options ({c,cxx}.mode). This makes them accessible from ad hoc recipes. The original mode/path are available in {c,cxx}.config.mode/path. * Generation of a common pkg-config .pc file in addition to static/shared- specific. The common .pc file is produced by ignoring any static/shared-specific poptions and splitting loptions/libs into Libs/Libs.private. It is "best effort", in a sense that it's not guaranteed to be sufficient in all cases, but it will probably cover the majority of cases, even on Windows, thanks to automatic dllimport'ing of functions. * The ~host configuration now only contains the cc and bin modules configuration. There is also the new ~build2 configuration that contains everything (except config.dist.*) and is meant to be used for build system modules. * Reworked tool importation support. Specifically, now config. (like config.cli) is handled by the import machinery (it is a shorter alias for config.import...exe that we already had). This also adds support for uniform tool metadata extraction that is handled by the import machinery. As a result, a tool that follows the "build2 way" can be imported with metadata by the buildfile and/or corresponding module without any tool-specific code or brittleness associated with parsing --version or similar outputs. See the cli tool/module for an example of how this all fits together. Finally, two new flavors of the import directive are now supported: import! triggers immediate importation skipping any rule-specific logic while import? is optional import (analogous to using?). Note that optional import is always immediate. There is also the import-specific metadata attribute which can be specified for these two import flavors in order to trigger metadata importation. For example: import? [metadata] cli = cli%exe{cli} if ($cli != [null]) info "cli version $($cli:cli.version)" * Backtick (`) and bit-or (|) are reserved in eval context for future use. Specifically, they are reserved for planned support of arithmetic eval contexts and evaluation pipelines, respectively. Version 0.12.0 * Support for dynamically-buildable/loadable build system modules. See the libbuild2-hello sample module to get started: https://github.com/build2/libbuild2-hello * Support for pattern matching (switch). For example: switch $cxx.target.class, $cxx.target.system { case 'windows', 'mingw32' cxx.libs += -lrpcrt4 case 'windows' cxx.libs += rpcrt4.lib case 'macos' cxx.libs += -framework CoreFoundation } See the "Pattern Matching (switch)" section in the manual for details. * Support for default options files (aka tool config files). See the DEFAULT OPTIONS FILES section in b(1) for details. * Support for Clang targeting MSVC runtime on Windows. In particular, the build2 toolchain itself can now be built with Clang on Windows, including using LLD. See the "Clang Compiler Toolchain" section in the manual for details. * Support for automatic installation discovery for MSVC 15 (2017) and later. In particular, this allows building outside the Visual Studio development command prompts. See the "MSVC Compiler Toolchain" section in the manual for details. * Ability to specify "compiler mode" options as part of config.{c,cxx}. Such options are not overridden in buildfiles and are passed last (after cc.coptions and {c,cxx}.coptions) in the resulting command lines. Note that they are also cross-hinted between config.c and config.cxx. For example: $ b config.cxx="g++-9 -m32" # implies config.c="gcc-9 -m32" But: $ b config.cxx="clang++ -stdlib=libc++" config.c=clang * Support for [config.]{cc,c,cxx}.aoptions (archive options). In particular, this can be used to suppress lib.exe warnings, for example: cc.aoptions += /IGNORE:4221 * The cxx.std=latest value has been remapped from c++latest to c++17 for MSVC 16 (2019). See issue #34 for background: https://github.com/build2/build2/issues/34 * Support for bracket expressions ([...]) in wildcard patterns. See the "Name Patterns" section in the manual for details. * Support for native shared library versioning on Linux. Now we can do: lib{foo}: bin.lib.version = linux@1.2 And end up with: libfoo.so.1.2 libfoo.so.1 -> libfoo.so.1.2 See issue #49 for background and details: https://github.com/build2/build2/issues/49 * Changes to the Buildfile language functions: - $string.icasecmp(): new - $regex.replace_lines(): new - $regex.{match,search}(): now return NULL on no match with return_* flags - $filesystem.path_match(): renamed to $path.match() - $quote(): new This function can be useful if we want to pass a value on the command line, for example, in a testscript: $* config.cxx=$quote($recall($cxx.path) $cxx.mode, true) - $config.save(): new This is similar to the config.config.save variable functionality (see below) except that it can be called from within buildfiles and with the result saved in a variable, printed, etc. Note that this function can only be used during configure unless the config module creation was forced for other meta-operations with config.config.module=true in bootstrap.build. * Support for configuration exporting and importing. The new config.config.save variable specifies the alternative file to write the configuration to as part of the configure meta-operation. For example: $ b configure: proj/ config.config.save=proj-config.build The config.config.save value "applies" only to the projects on whose root scope it is specified or if it is a global override (the latter is a bit iffy but we allow it, for example, to dump everything to stdout). This means that in order to save a subproject's configuration we will have to use a scope-specific override (since the default will apply to the outermost amalgamation). For example: $ b configure: subproj/ subproj/config.config.save=.../subproj-config.build This is somewhat counter-intuitive but then it will be the amalgamation whose configuration we would normally want to export. The new config.config.load variable specifies additional configuration files to be loaded after the project's default config.build, if any. For example: $ b create: cfg/,cc config.config.load=.../my-config.build Similar to config.config.save, the config.config.load value "applies" only to the project on whose root scope it is specified or if it is a global override. This allows the use of the standard override "positioning" machinery (i.e., where the override applies) to decide where the extra configuration files are loaded. The resulting semantics is quite natural and consistent with command line variable overrides, for example: $ b config.config.load=.../config.build # outermost amalgamation $ b ./config.config.load=.../config.build # this project $ b !config.config.load=.../config.build # every project Both config.config.load and config.config.save recognize the special `-` file name as an instruction to read/write from/to stdin/stdout, respectively. For example: $ b configure: src-prj/ config.config.save=- | \ b configure: dst-prj/ config.config.load=- The config.config.load also recognizes the `~host` special configuration name. This is the "default host configuration" that corresponds to how the build system itself was built. For example: $ b create: tools/,cc config.config.load=~host * Attributes are now comma-separated with support for arbitrary values. Before: x = [string null] After: x = [string, null] * The build system has been split into a library (libbuild2) a set of modules, and a driver. See the following mailing list post for details: https://lists.build2.org/archives/users/2019-October/000687.html As part of this change the following configuration macros (normally supplied via the -D preprocessor options) have been renamed from their old BUILD2_* versions to: LIBBUILD2_MTIME_CHECK LIBBUILD2_SANE_STACK_SIZE LIBBUILD2_DEFAULT_STACK_SIZE LIBBUILD2_ATOMIC_NON_LOCK_FREE * A notion of build context. All the non-const global state has been moved to class context and we can now have multiple independent builds at the same time. In particular, this functionality is used to update build system modules as part of another build. * New --silent options. Now in certain contexts (for example, while updating build system modules) the --quiet|-q verbosity level is ignored. We can specify --silent instead to run quietly in all contexts. * Support for the for_install prerequisite-specific variable. Setting this variable to true or false controls whether a prerequisite will be used by the link rule depending on whether the update is for install or not. Also reserve for_test for future use. * New config.config.persist variable. This variable is part of the initial support for customizable config.* variable persistence. * New bin.lib.load_suffix variable. Setting this variable triggers the creation of yet another symlink to the shared library that is meant to be used for dynamic loading. For example, we may want to embed the main program interface number into its plugins to make sure that we only load compatible versions. * New bin.lib.{version_pattern,load_suffix_pattern} variables. These variables allow specifying custom version and load suffix patterns that are used to automatically cleanup files corresponding to previous versions. * Rename the config.cxx.importable_headers variable to config.cxx.translatable_headers. The new name aligns better with the post-Cologne importable/translatable semantics. * The libu{} target group has been removed. The semantics provided by libu{} is rarely required and as a result has not yet been documented. However, if you are using it, the new way to achieve the same result is to use both libue{} and libul{} explicitly, for example: exe{foo}: libue{foo} lib{foo}: libul{foo} {libue libul}{foo}: cxx{*} Version 0.11.0 * Initial work on header unit importation and include translation support. In particular, for GCC, the (experimental) module mapper approach is now used to handle header unit importation, include translation, and headers dependency extraction, all with support for auto-generated headers. * Generalized target/prerequisite variable blocks. Target/prerequisite-specific variable blocks can now be present even if there are prerequisites. For example, now instead of: exe{foo}: cxx{foo} exe{foo}: cc.loptions += -rdynamic Or: exe{foo}: cxx{foo} exe{foo}: { cc.loptions += -rdynamic cc.libs += -ldl } We can write: exe{foo}: cxx{foo} { cc.loptions += -rdynamic cc.libs += -ldl } This also works with dependency chains in which case the block applies to the set of prerequisites (note: not targets) before the last ':'. For example: ./: exe{foo}: libue{foo}: cxx{foo} { bin.whole = false # Applies to the libue{foo} prerequisite. } * Support for ad hoc target groups. In certain cases we may need to instruct the underlying tool (compiler, linker, etc) to produce additional outputs. For example, we may want to request the compiler to produce an assembler listing or the linker to produce a map file. While we could already pass the required options, the resulting files will not be part of the build state. Specifically, they will not be cleaned up and we cannot use them as prerequisites of other targets. Ad hoc target groups allow us to specify that updating a target produces additional outputs, called ad hoc group members. For example: : cxx{hello} { cc.loptions += "-Wl,-Map=$out_base/hello.map" } : { cc.coptions += "-Wa,-amhls=$out_base/hello.lst" } Note also that all things ad hoc (prerequisites, targets, rules) are still under active development so further improvements (such as not having to repeat names twice) are likely. * New config.{c,cxx}.std configuration variables that, if present, override {c,cxx}.std specified at the project level. In particular, this allows forcing a specific standard for all the projects in a build configuration, for example: $ b create: exp-conf/,cc config.cxx=g++ config.cxx.std=experimental * New --dry-run|-n option instructs build rules to print commands without actually executing them. Note that commands that are required to create an accurate build state will still be executed and the extracted auxiliary dependency information saved. In other words, this is not the "don't touch the filesystem" mode but rather "do minimum amount of work to show what needs to be done". In particular, this mode is useful to quickly generate the compilation database, for example: $ b -vn clean update |& compiledb * Ability to disable automatic rpath, support for custom rpath-link. Specifically, the new config.bin.rpath.auto variable can be used to disable the automatic addition of prerequisite library rpaths, for example: $ b config.bin.rpath.auto=false Note that in this case rpath-link is still added where normally required and for target platforms that support it (Linux and *BSD). The new config.bin.rpath_link and config.bin.rpath_link.auto have the same semantics as config.bin.rpath* but for rpath-link. * Enable MSVC strict mode (/permissive-) for 'experimental' standard starting from version 15.5. Version 0.10.0 * Support for an alternative build file/directory naming scheme. Now the build/*.build, buildfile, and .buildignore filesystem entries in a project can alternatively (but consistently) be called build2/*.build2, build2file, and .build2ignore. See a note at the beginning of the "Project Structure" section in the manual for details (motivation, restrictions, etc). * Support for multiple variable overrides. Now we can do: $ b config.cxx.coptions=-O3 config.cxx.coptions=-O0 Or even: $ b config.cxx.coptions=-O3 config.cxx.coptions+=-g * Support for MSVC 16 (2019). * Support for automatic switching to option files (AKA response files) on Windows if the linker command line is too long. This covers both MSVC link.exe/lib.exe and MinGW gcc.exe/ar.exe. Version 0.9.0 * New "Diagnostics and Debugging" section in the manual on debugging build issues. * Support for dependency chains. Now instead of: ./: exe{foo} exe{foo}: cxx{*} We can write: ./: exe{foo}: cxx{*} Or even: ./: exe{foo}: libue{foo}: cxx{*} This can be combined with prerequisite-specific variables (which naturally only apply to the last set of prerequisites in the chain): ./: exe{foo}: libue{foo}: bin.whole = false * Support for target and prerequisite specific variable blocks. For example, now instead of: lib{foo}: cxx.loptions += -static lib{foo}: cxx.libs += -lpthread We can write: lib{foo}: { cxx.loptions += -static cxx.libs += -lpthread } The same works for prerequisites as well as target type/patterns. For example: exe{*.test}: { test = true install = false } * Fallback to loading outer buildfile if there isn't one in the target's directory (src_base). This covers the case where the target is defined in the outer buildfile which is common with non-intrusive project conversions where everything is built from a single root buildfile. * Command line variable override scope syntax is now consistent with buildfile syntax. Before: $ b dir/:foo=bar ... After: $ b dir/foo=bar Alternatively (the buildfile syntax): $ b 'dir/ foo=bar' Note that the (rarely used) scope visibility modifier now leads to a double slash: $ b dir//foo=bar * Support for relative to base scope command line variable overrides. Currently, if we do: $ b dir/ ./foo=bar The scope the foo=bar is set on is relative to CWD, not dir/. While this may seem wrong at first, this is the least surprising behavior when we take into account that there can be multiple dir/'s. Sometimes, however, we do want the override directory to be treated relative to (every) target's base scope that we are building. To support this we are extending the '.' and '..' special directory names (which are still resolved relative to CWD) with '...', which means "relative to the base scope of every target in the buildspec". For example: $ b dir/ .../foo=bar Is equivalent to: $ b dir/ dir/foo=bar And: $ b liba/ libb/ .../tests/foo=bar Is equivalent to: $ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar * New config.{c,cxx}.{id,version,target} configuration variables. These variables allow overriding guessed compiler id/version/target, for example, in case of mis-guesses or when working with compilers that don't report their base (e.g., GCC, Clang) with -v/--version (common in the embedded space). * New --[no-]mtime-check options to control backwards modification time checks at runtime. By default the checks are enabled only for the staged toolchain. * New --dump option, remove state dumping from verbosity level 6. * The info meta-operation now prints the list of operations and meta- operations supported by the project. * New sleep Testscript builtin. Version 0.8.0 * BREAKING: rename the .test extension (Testscript file) to .testscript and the test{} target type to testscript{}. * Introduction chapter in the build system manual. The introduction covers every aspect of the build infrastructure, including the underlying concepts, for the canonical executable and library projects as produced by bdep-new(1). * New 'in' build system module. Given test.in containing something along these lines: foo = $foo$ Now we can do: using in file{test}: in{test.in} file{test}: foo = FOO The alternative variable substitution symbol can be specified with the in.symbol variable and lax (instead of the default strict) mode with in.substitution. For example: file{test}: in.symbol = '@' file{test}: in.substitution = lax * New 'bash' build system module that provides modularization support for bash scripts. See the build system manual for all the details. * Support for 'binless' (binary-less aka header-only) libraries. A header-only library (or, in the future, a module interface-only library) is not a different kind of library compared to static/shared libraries but is rather a binary-less, or binless for short, static or shared library. Whether a library is binless is determined dynamically and automatically based on the absence of source file prerequisites. See the build system manual for details. * Use thin archives for utility libraries if available. Thin archives are supported by GNU ar since binutils 2.19.1 and LLVM ar since LLVM 3.8.0. * Support for archive checksum generation during distribution: Now we can do: $ b dist: ... \ config.dist.archives='tar.gz zip' \ config.dist.checksums='sha1 sha256' And end up with .tar.gz.sha1, .tar.gz.sha256, .zip.sha1, and .zip.sha256 checksum files in addition to archives. * Support for excluded and ad hoc prerequisites: The inclusion/exclusion is controlled via the 'include' prerequisite- specific variable. Valid values are: false - exclude true - include adhoc - include but treat as an ad hoc input For example: lib{foo}: cxx{win32-utility}: include = ($cxx.targe.class == 'windows') exe{bar}: libs{plugin}: include = adhoc * C++ Modules support: - handle the leading 'module;' marker (p0713) - switch to new GCC module interface (-fmodule-mapper) - force reprocessing for module interface units if compiling with MSVC * Testscript: - new mv builtin - new --after option in touch builtin * New $process.run() and $process.run_regex() functions: $process.run([ ...]) Return trimmed stdout. $process.run_regex([ ...], [, ]) Return stdout lines matched and optionally processed with regex. Each line of stdout (including the customary trailing blank) is matched (as a whole) against and, if successful, returned, optionally processed with , as an element of a list. * Support for name patterns without wildcard characters. In particular, this allows the "if-exists" specification of prerequisites, for example: for t: $tests exe{$t}: cxx{$t} test{+$t} * Functions for decomposing name as target/prerequisite name: $name.name() $name.extension() $name.directory() $name.target_type() $name.project() * Add support for default extension specification, trailing dot escaping. For example: cxx{*}: extension = cxx cxx{foo} # foo.cxx cxx{foo.test} # foo.test (probably what we want...) cxx{foo.test...} # foo.test.cxx (... is this) cxx{foo..} # foo. cxx{foo....} # foo.. cxx{foo.....} # error (must come in escape pairs) * Use (native) C and C++ compilers we were built with as defaults for config.c and config.cxx, respectively. * Implement missing pieces in utility libraries support. In particular, we can now build static libraries out of utility libraries. * Built-in support for Windows module definition files (.def/def{}). * Project names are now sanitized when forming the config.import. variables. Specifically, '-', '+', and '.' are replaced with '_' to form a "canonical" variable name. Version 0.7.0 * Initial support for Clang targeting MSVC runtime (native Clang interface, not the clang-cl wrapper). * C++ Modules TS introduction, build system support, and design guidelines documentation. * New {c,cxx}.guess modules. These can be loaded before {c,cxx} to guess the compiler. Based on this information we can then choose the standard, experimental features, etc. For example: using cxx.guess if ($cxx.id == 'clang') cxx.features.modules = false cxx.std = experimental using cxx * New {c,cxx}.class variables. Compiler class describes a set of compilers that follow more or less the same command line interface. Compilers that don't belong to any of the existing classes are in classes of their own (say, Sun CC would be on its own if we were to support it). Currently defined compiler classes: gcc gcc, clang, clang-apple, icc (on non-Windows) msvc msvc, clang-cl, icc (Windows) * Support for C/C++ runtime/stdlib detection ({c,cxx}.{runtime,stdlib} variables; see cc/guess.hxx for possible values). * New __build2_preprocess macro. If cc.reprocess is true, the __build2_preprocess is defined during dependency extraction. This can be used to work around separate preprocessing bugs in the compiler. * Support for for-loop. The semantics is similar to the C++11 range-based for: list = 1 2 3 for i: $list print $i Note that there is no scoping of any kind for the loop variable ('i' in the above example). In the future the plan is to also support more general while-loop as well as break and continue. * New info meta operation. This meta operation can be used to print basic information (name, version, source/output roots, etc) for one or more projects. * New update-for-{test,install} operation aliases. * Support for forwarded configurations with target backlinking. See the configure meta-operation discussion in b(1) for details. * Improvements to the in module (in.symbol, in.substitution={strict|lax}). * New $directory(), $base(), $leaf() and $extension() path functions. * New $regex.split(), $regex.merge() and $regex.apply() functions. * Support for (parallel) bootstrapping using GNU make makefile. * Support for chroot'ed install (aka DESTDIR): b config.install.root=/usr config.install.chroot=/tmp/install * Support for prerequisite-specific variables, used for the bin.whole variable ("link whole archive"). * Regularize directory target/scope-specific variable assignment syntax: $out_root/: foo = bar # target $out_root/ foo = bar # scope $out_root/ { foo = bar # scope } * Support for structured result output (--structured-result). * Support for build hooks. The following buildfiles are loaded (if present) at appropriate times from the out_root subdirectories of a project: build/bootstrap/pre-*.build # before loading bootstrap.build build/bootstrap/post-*.build # after loading bootstrap.build build/root/pre-*.build # before loading root.build build/root/post-*.build # after loading root.build * New run directive. Now it is possible to: run echo 'foo = bar' print $foo * New dump directive. It can be used to print (to stderr) a human-readable representation of the current scope or a list of targets. For example: dump # Dump current scope. dump lib{foo} details/exe{bar} # Dump two targets. This is primarily useful for debugging as well as to write build system tests. Version 0.6.0 * C++ Modules TS support for GCC, Clang, and VC. The new 'experimental' value of the cxx.std variable enables modules support if provided by the C++ compiler. The cxx.features.modules boolean variable can be used to control/query C++ modules enablement. See the "C++ Module Support" section in the build system manual for all the details. * Precise change detection for C and C++ sources. The build system now calculates a checksum of the preprocessed token stream and avoids recompilation if the changes are ignorable (whitespaces, comments, unused macros, etc). To minimize confusion ("I've changed my code but nothing got updated"), the build system prints a 'skip' line for ignored changes. * Initial support for utility libraries. A utility library is an archive that "mimics" the object file type (executable, static library, or shared library) of its "primary" target. Unless explicitly overridden, utility libraries are linked in the "whole archive" mode. For example: exe{prog}: cxx{prog} libu{prog} libu{prog}: cxx{* -prog} # Unit tests. # tests/ { libu{*}: bin.whole = false # Don't link whole. exe{test1}: cxx{test1} ../libu{prog} exe{test2}: cxx{test2} ../libu{prog} } This change adds the new target group libu{} and its libue{}, libua{}, and libus{} members. Note that the bin.whole variable can also be used on normal static libraries. * Progress display. The build system will now display build progress for low verbosity levels and if printing to a terminal. It can also be explicitly requested with the -p|--progress option and suppressed with --no-progress. Note that it is safe to enable progress even when redirecting to a file, for example: b -p 2>&1 | tee build.log * Support for generating pkg-config's .pc files on install. These files are now generated by default and automatically for libraries being installed provided the version, project.summary, and project.url variables are defined. The version module has been improved to extract the summary and url in addition to the version from the manifest. * Support for the '20' cxx.std value (C++20/c++2a). * The fail, warn, info, and text directives in addition to print. For example: if ($cxx.id.type == 'msvc') fail 'msvc is not supported' * New build system functions: - $getenv() -- query environment variable value - $filesystem.path_{search,match}() -- wildcard pattern search/match - $regex.{match,search,replace}() -- regex match/search/replace * New Testscript builtins: - ln - exit (pseudo-builtin) * Separate C and C++ (partial) preprocessing and compilation for Clang, GCC, and VC. This is part of the infrastructure that is relied upon by the C++ modules support, precise change detection support, and, in the future, by distributed compilation. There is also the ability to limit the amount of preprocessing done on a source file by setting the {c,cxx}.preprocessed variables. Valid values are 'none' (not preprocessed), 'includes' (no #include directives in the source), 'modules' (as above plus no module declarations depend on the preprocessor, for example, #ifdef, etc.), and 'all' (the source is fully preprocessed). Note that for 'all' the source may still contain comments and line continuations. While normally unnecessary, the use of the (partially) preprocessed output in compilation can be disabled. This can be done from a buildfile for a scope (including project root scope) and per target via the cc.reprocess variable: cc.reprocess = true obj{hello}: cc.reprocess = false As well as externally via the config.cc.reprocess variable: b config.cc.reprocess=true Version 0.5.0 * Parallel build system execution, including header dependency extraction and compilation. * Support for Testscript, a shell-like language for portable and parallel execution of tests. See the Testscript manual for details. * Support for name generation with wildcard patterns. For example: exe{hello}: cxx{*} Or: ./: {*/ -build/} See the build system manual for details. * New module, version, automates project version management. See the build system manual for details. * Support for VC15, C++ standard selection in VC14U3 and up. * New meta-operation, create, allows the creation and configuration of an amalgamation project. See b(1) for details. * Alternative, shell-friendly command line buildspec and variable assignment syntax. For example: b test: foo/ bar/ b config.import.libhello = ../libhello/ See b(1) for details. * Automatic loading of directory buildfiles, implied directory buildfiles. Now instead of explicitly writing: d = foo/ bar/ ./: $d doc{README} include $d We can just write: ./: foo/ bar/ doc{README} And if our buildfile simply builds all the subdirectories: ./: */ Then it can be omitted altogether. * Support of the PATH-based search as a fallback import mechanism for exe{} targets. * Support for the 'latest' value in the cxx.std variable which can be used to request the latest C++ standard available in the compiler. * Ternary and logical operators support in eval contexts. * Initial support for build system functions. See build2/function*.?xx for early details. * Assert directive. The grammar is as follows: assert [] assert! [] The expression must evaluate to 'true' or 'false', just like in if-else. Version 0.4.0 * Support for Windows. The toolchain can now be built and used on Windows with either MSVC or MinGW GCC. With VC, the toolchain can be built with version 14 Update 2 or later and used with any version from 7.1. /MD and, for C++, /EHsc are default but are overridden if an explicit value is specified in the coptions variable. * Support for C compilation. There is now the 'c' module in addition to 'cxx' as well as 'cc', which stands for C-common. Mixed source (C and C++) building is also supported. * Integration with pkg-config. Note that build2 doesn't use pkg-config to actually locate the libraries (because this functionality of pkg-config is broken when it comes to cross-compilation). Rather, it searches for the library (in the directories extracted from the compiler) itself and then looks for the corresponding .pc file (normally in the pkgconfig/ subdirectory of where it found the library). It then calls pkg-config to extract any additional options that might be needed to use the library from this specific .pc file. * Initial support for library versioning. Currently, only platform-independent versions are supported. They get appended to the library name/soname. For example: lib{foo}: bin.lib.version = @-1.2 This will produce libfoo-1.2.so, libfoo-1.2.dll, etc. In the future the plan is to support platform-specific versions, for example: lib{foo}: bin.lib.version = linux@1.2.3 freebsd@1.2 windows@1.2 * Library dependency export support. In build2 a library dependency on another library is either an "interface" or "implementation". If it is an interface, then everyone who links this library should also be linking the interface dependency. A good example of an interface dependency is a library API that is called in an inline function. Interface dependencies of a library should be explicitly listed in the *.export.libs variable (where we can now list target names). The typical usage will be along these lines: import int_libs = libformat%lib{format} import int_libs += ... import imp_libs = libprint%lib{print} import imp_libs += ... lib{hello}: ... $imp_libs $int_libs lib{hello}: cxx.export.libs = $int_libs There is support for symbol exporting on Windows and build2 now also does all the right things when linking static vs shared libraries with regards to which library dependencies to link, which -rpath/-rpath-link options to pass, etc. * Support for the uninstall operation in addition to install. * Support for preserving subdirectories when installing. This is useful, for example, when installing headers: install.include = $install.include/foo/ install.include.subdirs = true The base for calculating the subdirectories is the scope where the subdirs value is set. * Support for installing as a different file name. Now the install variable is a path, not dir_path. If it is a directory (ends with a trailing slash), then the target is installed into this directory with the same name. Otherwise, the entire path is used as the installation destination. * Support for config.bin.{,lib,exe}.{prefix,suffix}. This replaces the bin.libprefix functionality. * Support for global config.install.{cmd,options,sudo,mode,dir_mode}. This way we can do: b install \ config.install.data_root=/opt/data \ config.install.exec_root=/opt/exec \ config.install.sudo=sudo * The new -V option is an alias for --verbose 3 (show all commands). * Support for specifying directories in config.dist.archives. For example, this command will create /tmp/foo-X.Y.Z.tar.xz: b foo/ config.dist.archives=/tmp/tar.xz * The cxx (and c) module is now project root-only. This means these modules can only be loaded in the project root scope (normally root.build). Also, the c.std and cxx.std values must now be set before loading the module to take effect. * The test, dist, install, and extension variables now have target visibility to prevent accidental "reuse" for other purposes. * An empty config.import.* value is now treated as an instruction to skip subproject search. Also, explicit config.import.* values now take precedence over the subproject search. * Search for subprojects is no longer recursive. In the future the plan is to allow specifying wildcard paths (* and **) in the subprojects variable. * Support out-qualified target syntax for setting target-specific variables on targets from src_base. For example: doc{INSTALL}@./: install = false * Only "effective escaping" (['"\$(]) is now performed for values on the command line. This makes for a more usable interface on Windows provided we use "sane" paths (no spaces, no (), etc). * The default variable override scope has been changed from "projects and subprojects" to "amalgamation". The "projects and subprojects" semantics resulted in counter-intuitive behavior. For example, in a project with tests/ as a subproject if one builds one of the tests directly with a non-global override (say C++ compiler), then the main project would be built without the overrides. In this light, overriding in the whole amalgamation seems like the right thing to do. The old behavior can still be obtained with explicit scope qualification, for example: b ./:foo=bar * The config.build format has been made more readable. Specifically, the order is now from the higher-level modules (e.g., c, cxx) to the lower-level (e.g., binutils) with imports coming first. The file now also includes an explicit version for incompatibility detected/migration in the future. * Support for <, >, <=, >= in the eval context. Now we can write: if ($build.version >= 40000) * Support for single line if-blocks. Now we can write: if true print true else print false Instead of having to do: if true { print true } else { print false } * Support for prepend/append in target type/pattern-specific variables. Semantically, these are similar to variable overrides and are essentially treated as "templates" that are applied on lookup to the "stem" value that is specific to the target type/name. For example: x = [string] a file{f*}: x =+ b sub/: { file{*}: x += c print $(file{foo}:x) # abc print $(file{bar}:x) # ac } * The obj*{} target type to exe/lib mapping has been redesigned. Specifically: - objso{} and libso{} target types have been renamed to objs{} and libs{} - obje{} has been added (so now we have obje{}, obja{}, and objs{}) - obje{} is now used for building exe{} - object file extensions now use "hierarchical extensions" that reflect the extension of the corresponding exe/lib target (instead of the -so suffix we used), specifically: obje{}: foo.o, (UNIX), foo.exe.o (MinGW), foo.exe.obj (MSVC) obja{}: foo.a.o (UNIX, MinGW), foo.lib.obj (MSVC) objs{}: foo.so.o (UNIX), foo.dylib.o (Darwin), foo.dll.o (MinGW), foo.dll.obj (MSVC) We now also have libi{} which is the Windows DLL import library. When used, it is the first ad hoc group member of libs{}. Version 0.3.0 * Support for High Fidelity Builds (HFB). The C++ compile and link rules now detect when the compiler, options, or input file set have changed and trigger the update of the target. Some examples of the events that would now trigger an automatic update are: * compiler change (e.g., g++ to clang++), upgrade, or reconfiguration * change of compile/link options (e.g., -O2 to -O3) * replacement of a source file (e.g., foo.cpp with foo.cxx) * removal of a file from a library/executable * New command line variable override semantics. A command line variable can be an override (=), prefix (=+), or suffix (+=), for example: b config.cxx=clang++ config.cxx.coptions+=-g config.cxx.poptions=+-I/tmp Prefixes/suffixes are applied at the outsets of values set in buildfiles, provided these values were set (in those buildfiles) using =+/+= and not an expansion, for example: b x=+P x+=S x = y print $x # P y S x =+ p x += s print $x # P p y s S But: x = A $x B print $x # A P p y s S B By default an override applies to all the projects mentioned in the buildspec as well as to their subprojects. We can restrict an override to not apply to subprojects by prefixing it with '%', for example: b %config.cxx=clang++ configure An override can also be made global (i.e., it applies to all projects, including the imported ones) by prefixing it with '!'. As an example, compare these two command lines: b config.cxx.coptions+=-g b '!config.cxx.coptions+=-g' In the first case only the current project and its subprojects will be recompiled with the debug information. In the second case, everything that the current project requires (e.g., imported libraries) will be rebuilt with the debug information. Finally, we can also specify the scope from which an override should apply. For example, we may only want to rebuild tests with the debug information: b tests/:config.cxx.coptions+=-g * Attribute support. Attributes are key or key=value pairs enclosed in [] and separated with spaces. They come before the entity they apply to. Currently we recognize attributes for variables and values. For variables we recognize the following keys as types: bool uint64 string path dir_path abs_dir_path name strings paths dir_paths names For example: [uint64] x = 01 print $x # 1 x += 1 print $x # 2 Note that variable types are global, which means you could type a variable that is used by another project for something completely different. As a result, typing of values (see below) is recommended over variables. If you do type a variable, make sure it has a namespace (typing of unqualified variables may become illegal). For values we recognize the same set of types plus 'null'. The value type is preserved in prepend/append (=+/+=) but not in assignment. For example: x = [uint64] 01 print $x # 1 x += 1 print $x # 2 x = [string] 01 print $x # 01 x += 1 print $x # 011 x = [null] print $x # [null] Value attributes can also be used in the evaluation contexts, for example: if ($x == [null]) if ([uint64] $x == [uint64] 0) * Support for scope/target-qualified variable expansion. For example: print $(dir/:x) print $(file{target}:x) print $(dir/file{target}:x) * Command line options, variables, and buildspec can now be specified in any order. This is especially useful if you want to re-run the previous command with -v or add a forgotten config variable: b test -v b configure config.cxx=clang++ * Support for the Intel C++ compiler on Linux. * Implement C++ compiler detection. Currently recognized compilers and their ids (in the [-] form): gcc GCC clang Vanilla Clang clang-apple Apple Clang (and the g++ "alias") icc Intel icpc msvc Microsoft cl.exe The compiler id, version, and other information is available via the following build system variables: cxx.id cxx.id.{type,variant} cxx.version cxx.version.{major,minor,patch,build} cxx.signature cxx.checksum cxx.target cxx.target.{cpu,vendor,system,version,class} * Implement ar/ranlib detection. The following information is available via the build system variables: bin.ar.signature bin.ar.checksum bin.ranlib.signature bin.ranlib.checksum * On update for install the C++ link rule no longer uses the -rpath mechanism for finding prerequisite libraries. * Set build.host, build.host.{cpu,vendor,system,version,class} build system variables to the host triplet. By default it is set to the compiler target build2 was built with but a more precise value can be obtained with the --config-guess option. * Set build.version, build.version.{major,minor,patch,release,string} build system variables to the build2 version. * Extracted header dependencies (-M*) are now cached in the auxiliary dependency (.d) files rather than being re-extracted on every run. This speeds up the up-to-date check significantly. * Revert back to only cleaning prerequisites if they are in the same project. Cleaning everything as long as it is in the same strong amalgamation had some undesirable side effects. For example, in bpkg, upgrading a package (which requires clean/reconfigure) led to all its prerequisites being cleaned as well and then rebuilt. That was surprising, to say the least. * Allow escaping in double-quoted strings. * Implement --buildfile option that can be used to specify the alternative file to read build information from. If '-' is specified, read from STDIN. * New scoping semantics. The src tree paths are no longer entered into the scope map. Instead, targets from the src tree now include their out tree directories (which are, in essence, their "configuration", with regards to variable lookup). The only user-visible result of this change is the extra '@/' suffix that is added when a target is printed, for example, as part of the compilation command lines. Version 0.2.0 * First public release.