diff options
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 520 |
1 files changed, 516 insertions, 4 deletions
@@ -1,3 +1,515 @@ +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. + + * Support for Assembler with C Preprocessor (.S) compilation. + + Specifically, the c module now provides the c.as-cpp submodules 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. + + * 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 forms of print_diag()): + + 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 GH issue #40 for additional background/details. + + * 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 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/ + + * The in.substitution variable has been renamed to in.mode. + + The original name is still recognized for backwards compatibility. + + * 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. + +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 +575,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 +1662,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 +1840,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. |