diff options
Diffstat (limited to 'NEWS')
-rw-r--r-- | NEWS | 1146 |
1 files changed, 1141 insertions, 5 deletions
@@ -1,6 +1,1117 @@ +Version 0.16.0 + + * Support for Objective-C/C++ compilation. + + Specifically, the c and cxx modules now provide the c.objc and cxx.objcxx + submodules which can be loaded in order to register the m{}/mm{} target + types and enable Objective-C/C++ compilation in the c and cxx compile + rules. Note that c.objc and cxx.objcxx must be loaded after the c and cxx + modules, respectively, and while the m{}/mm{} target types are registered + unconditionally, compilation is only enabled if the C/C++ compiler + supports Objective-C/C++ for this target platform. Typical usage: + + # root.build + # + using cxx + using cxx.objcxx + + # buildfile + # + lib{hello}: {hxx cxx}{*} + lib{hello}: mm{*}: include = ($cxx.target.class == 'macos') + + Note also that while there is support for linking Objective-C/C++ + executables and libraries, this is done using the C/C++ compiler driver + and no attempt to automatically link any necessary Objective-C runtime + (such as -lobjc) is made. For details, refer to "Objective-C Compilation" + and "Objective-C++ Compilation" in the manual. + + * Support for Assembler with C Preprocessor (.S) compilation. + + Specifically, the c module now provides the c.as-cpp submodule which can + be loaded in order to register the S{} target type and enable Assembler + with C Preprocessor compilation in the c compile rule. For details, refer + to "Assembler with C Preprocessor Compilation" in the manual. + + * Support for buildfile importation. + + A project can now export buildfiles that can then be imported by other + projects. This mechanism is primarily useful for exporting target type + definitions and ad hoc rules. + + Specifically, a project can now place *.build files into its build/export/ + subdirectory (or *.build2 and build2/export/ in the alternative naming + scheme). Such files can then be imported by other projects as buildfile{} + targets. For example: + + import thrift%buildfile{thrift-cxx} + + While for other target types the semantics of import is to load the + project's export stub and return the exported target, for buildfile{} the + semantics is to source the imported buildfile at the point of importation. + + Note that care must be taken when authoring exported buildfiles since they + will be sourced by other projects in unpredictable circumstances. In + particular, the import directive by default does not prevent sourcing the + same buildfile multiple times (neither in the same project nor in the same + scope). As a result, if certain parts must only be sourced once per + project (such as target type definitions), then they must be factored into + a separate buildfile (in build/export/) that is imported by the "main" + exported buildfile with the `once` attribute. For example, the above + thrift-cxx.build may contain: + + import [once] thrift%buildfile{thrift-cxx-target-type} + + See also "install Module" in the manual for details on the exported + buildfile installation. + + * Support for defining explicit (as opposed to ad hoc) target groups. + + A user-defined explicit target group must be derived from the group base + target type. If desired, it can be marked as "see-through", meaning that + when it is listed as a prerequisite of a target, the matching rule will + "see" its members, rather than the group itself. For example: + + define [see_through] thrift_cxx: group + + define thrift: file + thrift{*}: extension = thrift + + exe{hello}: cxx{hello} thrift_cxx{data} + thrift_cxx{data}: thrift{data} + + Explicit group members can be specified statically, injected by an ad hoc + rule, or extracted dynamically by the depdb-dyndep builtin (see the next + NEWS item). For example: + + thrift_cxx{data}<{hxx cxx}{data_constants}>: thrift{data} # Static. + + thrift_cxx{~'/(.+)/'}<{hxx cxx}{^'/\1_types/'}>: thrift{~'/\1/'} # Inject. + {{ + depdb dyndep --dyn-target ... # Dynamic. + }} + + * Support for dynamic target extraction in addition to prerequisites. + + This functionality is enabled with the depdb-dyndep --dyn-target option. + If the recipe target is an explicit group (see the previous NEWS item), + then the dynamically extracted targets are added as its members. + Otherwise, the listed targets are added as ad hoc group members. In both + cases the dynamically extracted target is ignored if it is already + specified as a static member or injected by a rule. Note that this + functionality is not available in the --byproduct mode. See the + depdb-dyndep builtin options description for details. + + * New `lines` depdb-dyndep dependency format in addition to `make`. + + The `lines` format lists targets and/or prerequisites one per line. See + the depdb-dyndep builtin options description for details. + + * Low verbosity diagnostics rework. + + The low verbosity (level 1) rule diagnostics format has been adjusted to + include the output target where appropriate. The implementation has also + been redesigned to go through the uniform print_diag() API, including for + the `diag` pseudo-builtin in ad hoc recipes. + + Specifically, the `diag` builtin now expects its arguments to be in one of + the following two forms (which correspond to the two print_diag() forms): + + diag <prog> <l-target> <comb> <r-target>... + diag <prog> <r-target>... + + If the `diag` builtin is not specified, the default diagnostics is now + equivalent to: + + For update: + + diag <prog> ($<[0]) -> $> + + And for other operations: + + diag <prog> $> + + For details, see the print_diag() API description in diagnostics.hxx. See + also GitHub issue #40 for additional background/details. + + * Buffering of diagnostics from child processes. + + By default, unless running serially or --no-diag-buffer is specified, + diagnostics issued by child processes (compilers, etc) is buffered and + printed all at once after each child exits in order to prevent + interleaving. See also the new --[no-]diag-color options. + + * New $path.posix_string() and $path.posix_representation() functions. + + These functions are similar to $path.string() and $path.representation() + except that they always return the string/representation of a path in the + POSIX notation, that is, using forward slashes. + + * New $regex.filter[_out]_{match,search}(<vals>, <pat>) functions. + + The match versions return elements of a list that match (filter) or do not + match (filter_out) the regular expression. The search versions do the same + except for the search instead of match regex semantics. + + * New $find(<sequence>, <value>), $find_index(<sequence>, <value>) functions. + + The $find() function returns true if the sequence contains the specified + value. The $find_index() function returns the index of the first element + in the sequence that is equal to the specified value or $size(<sequence>) + if none is found. For string sequences, it's possible to request case- + insensitive comparison with a flag, for example: + + if ($find ($values, 'foo', icase)) + ... + + * New $integer_sequence(<begin>, <end>[, <step>]) function. + + This function returns the list of uint64 integers starting from <begin> + (including) to <end> (excluding) with the specified <step> or 1 if + unspecified. For example: + + hdr = foo.hxx bar.hxx baz.hxx + src = foo.cxx bar.cxx baz.cxx + + assert ($size($hdr) == $size($src)) "hdr and src expected to be parallel" + + for i: $integer_sequence(0, $size($hdr)) + { + h = ($hdr[$i]) + s = ($src[$i]) + ... + } + + * New $is_a(<name>, <target-type>), $filter[_out](<names>, <target-types>) + functions. + + $is_a() returns true if the <name>'s target type is-a <target-type>. Note + that this is a dynamic type check that takes into account target type + inheritance. + + $filter[_out]() return names with target types which are-a (filter) or + not are-a (filter_out) one of <target-types>. + + In particular, these functions are useful for filtering prerequisite + targets ($<) in ad hoc recipes and rules. + + * Support for the hex notation for the uint64 type. + + Specifically, now we can do: + + x = [uint64] 0x0000ffff + + cxx.poptions += "-DOFFSET=$x" # -DOFFSET=65535 + cxx.poptions += "-DOFFSET=$string($x, 16)" # -DOFFSET=0xffff + cxx.poptions += "-DOFFSET=$string($x, 16, 8)" # -DOFFSET=0x0000ffff + + Note that there is no hex notation support for the int64 (signed) type. + + * Support for the `for` and `while` loops in Buildscript recipes and + Testscript. + + For example: + + for v: $values + ... + end + + cat values.txt | for -n v + ... + end + + while (!$regex.match(...)) + ... + end + + See "Command-For" and "Command-While" in the Testscript manual for + details. + + * New `find` builtin in Buildscript recipes and Testscript. + + For example: + + find gen/ -type f -name '*.?xx' | for -n f + ... + end + + See "find" in the Testscript manual for details. + + * Improvements to escape sequence support. + + In the double-quoted strings we now only do effective escaping of the + special [$("\] characters, line continuations, plus [)] for symmetry. + + There is now support for "escape sequence expansion" in the $\X form where + \X can be any of the C/C++ simple escape sequences (\n, \t, etc) plus \0 + (which in C/C++ is an octal escape sequence). For example: + + info "foo$\n$\tbar$\n$\tbaz" + + Will print: + + buildfile:1:1: info: foo + bar + baz + + * New include_arch installation location and the corresponding + config.install.include_arch configuration variable. + + This location is meant for architecture-specific files, such as + configuration headers. By default it's the same as the standard include + location but can be configured by the user to a different value (for + example, /usr/include/x86_64-linux-gnu/) for platforms that support + multiple architectures from the same installation location. This is how + one would normally use it from a buildfile: + + # The generated configuration header may contain target architecture- + # specific information so install it into include_arch/ instead of + # include/. + # + h{*}: install = include/libhello/ + h{config}: install = include_arch/libhello/ + + * Support for installation filtering. + + While project authors determine what gets installed at the buildfile + level, the users of the project can now further filter the installation + using the config.install.filter variable. For details, see "Installation + Filtering" in the manual. + + * Support for relocatable installations. + + A relocatable installation can be moved to a directory other than its + original installation location. To request a relocatable installation, set + the config.install.relocatable variable to true. For details, see + "Relocatable Installation" in the manual. + + * Support for installation manifest. + + During the install operation, the config.install.manifest variable can be + set to a file path (or `-`) in order to write the information about all + the filesystem entries being installed into the specified file (or + stdout). The format of the installation manifest is "JSON lines". For + details, see the config.install.manifest variable documentation in the + install module. + + * Ability to remap paths in source distributions. + + The dist target-specific variable can now specify a path besides true or + false. This path is the "imaginary" source location which is used to + derive the corresponding distribution location. This location can be + either a directory path (to remap with the same file name) or a file path + (to remap with a different name). If the path is relative, then it is + treated relative to the target directory. Note that to make things less + error-prone, simple paths without any directory separators are not allowed + (use ./<name> instead). + + Note that if multiple targets end up with the same source location, the + behavior is undefined and no diagnostics is issued. Note also that such + remapping has naturally no effect in the bootstrap distribution mode. + + * The in.substitution variable has been renamed to in.mode. + + The original name is still recognized for backwards compatibility. + + * Ability to specify `in` rule substitutions as key-value pairs. + + See "in Module" in the manual for details. + + * New public/private variables model. + + Now unqualified variables are project-private and can be typed, meaning + that a value assigned to a variable with such a name anywhere within the + project will have this type. For example: + + [uint64] priority = [null] + [uint64] stack_size = [null] + + priority = 1 # Ok. + stack_size = abc # Error. + + Besides the type, variable attributes can specify visibility (project by + default) and overridability (false by default). For example: + + thread{*}: + { + [uint64, visibility=target] priority = [null] + [uint64, visibility=target] stack_size = [null] + } + + thread{foo}: priority = 1 # Ok. + priority = 1 # Error. + + * Support for post hoc prerequisites. + + Unlike normal and ad hoc prerequisites, a post hoc prerequisite is built + after the target, not before. It may also form a dependency cycle together + with normal/ad hoc prerequisites. In other words, all this form of + dependency guarantees is that a post hoc prerequisite will be built if its + dependent target is built. + + A canonical example where this can be useful is a library with a plugin: + the plugin depends on the library while the library would like to make + sure the plugin is built whenever the library is built so that programs + that link the library can be executed without having to specify explicit + dependency on the plugin (at least for the dynamic linking case): + + lib{hello}: ... + lib{hello-plugin}: ... lib{hello} + libs{hello}: libs{hello-plugin}: include = posthoc + + Note that there is no guarantee that post hoc prerequisites will be built + before the dependents of the target "see" it as built. Rather, it is + guaranteed that post hoc prerequisites will be built before the end of the + overall build (more precisely, before the current operation completes). + As a result, post hoc prerequisites should not be relied upon if the + result (for example, a source code generator) is expected to be used + during build (more precisely, within the same operation). + + Note also that the post hoc semantics is not the same as order-only in + GNU make. In fact, it is an even more "relaxed" form of dependency. + Specifically, while order-only prerequisite is guaranteed to be built + before the target, post hoc prerequisite is only guaranteed to be built + before the end of the overall build. + + * Support for dumping build system state in the JSON format. + + The new --dump-format option can be used to select the desired format. + Its valid values are `buildfile` and `json-v0.1`. For details on the JSON + dump format see "Appendix A - JSON Dump Format" in the manual. + + * Change to the --dump option semantics. + + This option now recognizes two additional values: `match-pre` and + `match-post` to dump the state of pre/post-operations. The `match` value + now only triggers dumping of the main operation. + + * New --dump-scope and --dump-target options to limit --dump output. + + * New --load-only option in addition to --match-only. + + This option has the effect of loading all the subdirectory buildfiles that + are not explicitly included and is primarily useful in combination with + --dump. + + * Quoted/display target names in the JSON structured result are now + consistent with the JSON dump. + + Specifically, before we had `target` (display) and `quoted_target` and now + we have `target` (quoted) and `display_target`. Note that this is a + backwards-incompatible change. + + * The dist meta-operation no longer invokes the install program. + + This results in a substantial speedup, especially on Windows. The use of + install (or another install-like program) can still be forced with + explicit config.dist.cmd=install. + + * Clang -Wunqualified-std-cast-call warning was remapped to -Wextra. + + Clang 15 introduced the -Wunqualified-std-cast-call warning which warns + about unqualified calls to std::move() and std::forward() (because they + can be "hijacked" via ADL). Surprisingly, this warning is enabled by + default, as opposed to with -Wextra or at least -Wall. It has also proven + to be quite disruptive, causing a large number of warnings in a large + number of packages. So we have "remapped" it to -Wextra for now and in the + future may "relax" it to -Wall and potentially to being enabled by + default. See GitHub issue #259 for background and details. + +Version 0.15.0 + + * Generated C/C++ headers and ad hoc sources are now updated during match. + + Specifically, all headers as well as ad hoc headers and sources are now + treated by the cc::link_rule as if they had update=match unless explicit + update=execute is specified (see below on the update operation-specific + variable). + + This change should be transparent to most projects. For background and + discussion of rare cases where you may wish to disable this, see: + + https://github.com/build2/HOWTO/blob/master/entries/handle-auto-generated-headers.md + + * Support for rule hints. + + A rule hint is a target attribute, for example: + + [rule_hint=cxx] exe{hello}: c{hello} + + Rule hints can be used to resolve ambiguity when multiple rules match the + same target as well as to override an unambiguous match. + + In cc::link_rule we now support "linking" libraries without any sources or + headers with a hint. This can be useful for creating "metadata libraries" + whose only purpose is to convey metadata (options to use and/or libraries + to link). + + * UTF-8 is now the default input/source character set for C/C++ compilation. + + Specifically, the cc module now passes the appropriate compiler option + (/utf-8 for MSVC and -finput-charset=UTF-8 for GCC and Clang) unless a + custom value is already specified (with /{source,execution}-charset for + MSVC and -finput-charset for GCC and Clang). + + This change may trigger new compilation errors in your source code if + it's not valid UTF-8 (such errors most commonly point into comments). + For various ways to fix this, see: + + https://github.com/build2/HOWTO/blob/master/entries/convert-source-files-to-utf8.md + + * Project configuration variables are now non-nullable by default. + + A project configuration variable with the NULL default value is naturally + assumed nullable, for example: + + config [string] config.libhello.fallback_name ?= [null] + + Otherwise, to make a project configuration nullable use the `null` + variable attribute, for example: + + config [string, null] config.libhello.fallback_name ?= "World" + + * New $relative(<path>, <dir-path>) function. + + * New $root_directory(<path>) function. + + * New $size() function to get the size of string, path, dir_path. + + * New $size() function to get the size of a sequence (strings, paths, etc). + + * New $sort() function to sort a sequence (strings, paths, etc). + + The function has the following signature: + + $sort(<sequence> [, <flags>]) + + The following flag is supported by all the overloads: + + dedup - in addition to sorting also remove duplicates + + Additionally, the strings overload also support the following flag: + + icase - sort ignoring case + + Note that on case-insensitive filesystems the paths and dir_paths + overloads' order is case-insensitive. + + * New $config.origin() function for querying configuration value origin. + + Give a config.* variable name, this function returns one of `undefined`, + `default`, `buildfile`, or `override`. + + * Recognition of -pthread as a special -l option in *.libs. + + For background, see: + + https://github.com/build2/HOWTO/blob/master/entries/link-pthread.md + + * The bin.whole (whole archive) value is now saved in generated pkg-config + files. + + * Ability to customize header and library search paths in generated + pkg-config files. + + Specifically, {cc,c,cxx}.pkgconfig.{include,lib} variables specify header + (-I) and library (-L) search paths to use in the generated pkg-config + files instead of the default install.{include,lib}. Relative paths are + resolved as installation paths. For example: + + lib{Qt6Core}: cxx.pkgconfig.include = include/qt6/ + + * Ability to save user metadata in C/C++ libraries, including in generated + pkg-config files. + + For background and details, see: + + https://github.com/build2/HOWTO/blob/master/entries/convey-additional-information-with-exe-lib.md + + * Support for rule-specific search in immediate import. + + We can now nominate a rule to perform the rule-specific search (if + required) using the rule_hint attribute. For example: + + import! [metadata, rule_hint=cxx.link] lib = libhello%lib{hello} + + * 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 <name> + + Dependency format. Currently only the `make` dependency format is + supported and is the default. + + --cwd <dir> + + 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). + + --adhoc + + Treat dynamically discovered prerequisites as ad hoc (so they don't end + up in $<; only in the normal mode). + + --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} <tgt>|<pat> + + 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($>) + + lib_poptions = $cxx.lib_poptions(libue{hello-meta}, obje) + depdb hash $lib_poptions + + poptions = $cxx.poptions $cc.poptions $lib_poptions + 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 + }} + + As another example, sometimes we need to extract the "common interface" + preprocessor options that are independent of the the library type (static + or shared). For example, the Qt moc compiler needs to "see" the C/C++ + preprocessor options from imported libraries if they could affect its + input. Here is how we can implement this: + + import libs = libhello%lib{hello} + + libul{hello-meta}: $libs + + cxx{hello-moc}: hxx{hello} libul{hello-meta} $moc + {{ + s = $path($<[0]) + o = $path($>[0]) + t = $(o).t + + lib_poptions = $cxx.lib_poptions(libul{hello-meta}) + depdb hash $lib_poptions + + depdb dyndep --byproduct --drop-cycles --what=header --default-type=h \ + --update-exclude libul{hello-meta} --file $t + + diag moc ($<[0]) + + $moc $cc.poptions $cxx.poptions $lib_poptions \ + -f $leaf($s) --output-dep-file --dep-file-path $t -o $o $s + }} + + Planned future improvements include support for the `lines` (list of + files, one per line) input format in addition to `make` and support for + dynamic targets in addition to prerequisites. + + * Support for specifying custom ad hoc pattern rule names. + + Besides improving diagnostics, this allows us to use such a name in the + rule hints, for example: + + [rule_name=hello.link] exe{~'/(.*)/'}: obje{~'/\1/'} + {{ + $cxx.path -o $path($>) $path($<[0]) + }} + + [rule_hint=hello] exe{hello}: obje{hello} + + obje{hello}: c{hello-c} + + * Ability to disfigure specific configuration variables. + + The new config.config.disfigure variable can be used to specify the list + of variables to ignore when loading config.build (and any files specified + in config.config.load), letting them to take on the default values. For + example: + + $ b configure config.config.disfigure=config.hello.fancy + + Besides names, variables can also be specified as patterns in the + config.<prefix>.(*|**)[<suffix>] form where `*` matches single + component names (i.e., `foo` but not `foo.bar`), and `**` matches + single and multi-component names. Currently only single wildcard (`*` or + `**`) is supported. Additionally, a pattern in the config.<prefix>(*|**) + form (i.e., without `.` after <prefix>) matches config.<prefix>.(*|**) + plus config.<prefix> itself (but not config.<prefix>foo). + + For example, to disfigure all the project configuration variables (while + preserving all the module configuration variables; note quoting to prevent + pattern expansion): + + $ b config.config.disfigure="'config.hello**'" + + * Ability to omit loading config.build. + + If the new config.config.unload variable is set to true, then omit loading + the project's configuration from the config.build file. Note that the + configuration is still loaded from config.config.load if specified. Note + also that similar to config.config.load, only overrides specified on this + project's root scope and global scope are considered. + + * Ability to match libul{} targets. + + The bin.libul rule picks, matches, and unmatches (if possible) a member + for the purpose of making its metadata (for example, library's poptions, + if it's one of the cc libraries) available. + + * Ability to get common interface options via ${c,cxx}.lib_poptions(). + + Specifically, the output target type may now be omitted for utility + libraries (libul{} and libu[eas]{}). In this case, only "common interface" + options will be returned for lib{} dependencies. This is primarily useful + for obtaining poptions to be passed to tools other than C/C++ compilers + (for example, Qt moc). + + * Ability to control -I translation to -isystem or /external:I in + ${c,cxx}.lib_poptions(). + + See the function documentation for details. + + * New `update` operation-specific variable. + + This variable is similar to the already existing `clean` and `test` + variables but besides the standard `true` and `false` values, it can also + be set to `unmatch` (match but do not update) and `match` (update during + match) and `execute` (update during execute, as is normally; this value is + primarily useful if the rule has the `match` semantics by default). + + Note that the unmatch (match but do not update) and match (update during + match) values are only supported by certain rules (and potentially only + for certain prerequisite types). + + Additionally: + + - All the operation-specific variables are now checked for `false` as an + override for the prerequisite-specific `include` variable. This can now + be used to disable a prerequisite for update, for example: + + ./: exe{test}: update = false + + - Ad hoc Buildscript recipes now support update=unmatch|match. + + - The cc::link_rule now supports the `match` value for headers and ad hoc + prerequisites. This can be used to make sure all the library headers are + updated before matching any of its (or dependent's) object files. + + * New build.mode global scope variable. + + This variable signals the mode the build system may be running in. The two + core modes are `no-external-modules` (bootstrapping of external modules is + disabled, see --no-external-modules for details) and `normal` (normal + execution). Other build system drivers may invent additional modes (for + example, the bpkg `skeleton` mode; see "Package Build System Skeleton" in + the package manager manual for details). + + * New cmdline value type for canned command lines. + + The Testscript and Buildscript languages now use the special cmdline value + type for canned command lines. Specifically, the re-lexing after expansion + now only happens if the expended value is of the cmdline type. See + "Lexical Structure" in the Testscript manual for details. + + * The bash build system module now installs bash modules into + bin/<project>.bash/ instead of bin/<project>/ to avoid clashes. + + * New --trace-{match,execute} options. + + These options can be used to understand which dependency chain causes + matching or execution of a particular target. See b(1) for details. + + * JSON format support for the --structured-result option and the info meta + operation. + + See b(1) for details. + + * Switch to using libpkg-config instead of libpkfconf for loading pkg-config + files. + Version 0.14.0 - * Allow unseparated scope-qualified variable assignment and expansion. + * 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: + + <exe{~'/(.*)/'} file{^'/\1.map/'}>: 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: + + <exe{~'/(.*)/'} file{^'/\1.map/'}>: 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: + + <exe{hello} file{hello.map}>: 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.<project>.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 <version> install directory substitution in addition to <project>. + 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: @@ -16,6 +1127,31 @@ Version 0.14.0 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. @@ -203,7 +1339,7 @@ Version 0.13.0 $ b config.install.private=foo install - See the "Install Module" chapter in the manual for details. + See the "install Module" chapter in the manual for details. * New $regex.find_{match,search}() functions that operate on lists. @@ -835,10 +1971,10 @@ Version 0.8.0 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: + in.mode. For example: file{test}: in.symbol = '@' - file{test}: in.substitution = lax + file{test}: in.mode = lax * New 'bash' build system module that provides modularization support for bash scripts. See the build system manual for all the details. @@ -1013,7 +2149,7 @@ Version 0.7.0 * 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}). + * Improvements to the in module (in.symbol, in.mode={strict|lax}). * New $directory(), $base(), $leaf() and $extension() path functions. |