aboutsummaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2021-10-11 11:08:56 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2021-10-11 11:08:56 +0200
commit8a7f0c22be9afb320749c7f010cd4189862a8bb6 (patch)
treec92857b2fb69870e051a7562d32a0d3381ada4a4 /NEWS
parent00c1d66eaa276d67b2d1eda1f4dd1e854b3bfaf3 (diff)
Update NEWS file
Diffstat (limited to 'NEWS')
-rw-r--r--NEWS340
1 files changed, 338 insertions, 2 deletions
diff --git a/NEWS b/NEWS
index 2f64076..01a3ff1 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,317 @@
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 "C++ 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.
+
+ The bin.def module (automatically loaded by the c and cxx modules for the
+ *-win32-msvc targets) provides a rule for generating symbol-exporting .def
+ files. This allows automatically exporting all symbols for all the Windows
+ targets/compilers using the following setup (showing for cxx in this
+ example):
+
+ lib{foo}: libul{foo}: {hxx cxx}{**} ...
+
+ lib{foo}: def{foo}: include = ($cxx.target.system == 'win32-msvc')
+ def{foo}: libul{foo}
+
+ if ($cxx.target.system == 'mingw32')
+ cxx.loptions += -Wl,--export-all-symbols
+
+ That is, we use the .def file generation for MSVC (including when building
+ with Clang) and the built-in support (--export-all-symbols) for MinGW.
+
+ Note that it is also possible to use the .def file generation for MinGW.
+ In this case we need to explicitly load the bin.def module (which should
+ be done after loading c or cxx) and can use the following setup:
+
+ using bin.def # In root.build after loading c/cxx.
+
+ lib{foo}: libul{foo}: {hxx cxx}{**} ...
+
+ lib{foo}: def{foo}: include = ($cxx.target.class == 'windows')
+ def{foo}: libul{foo}
+
+ * 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.
+
+ * 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 +327,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 +539,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.