diff options
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 829 |
1 files changed, 825 insertions, 4 deletions
@@ -1,3 +1,824 @@ +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 * Support for hermetic build configurations. @@ -63,7 +884,7 @@ Version 0.14.0 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} + <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++. @@ -1150,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. @@ -1328,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. |