aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2024-06-11 14:44:11 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2024-06-11 14:44:11 +0200
commita09cbea449850c679e27c83e4272bea399151996 (patch)
treefd206460aa0790f860915f6a0d9111f619f80e77
parent63bd5b82459036c647a521efb2c8668ceb520ec5 (diff)
Update NEWS file
-rw-r--r--NEWS391
1 files changed, 391 insertions, 0 deletions
diff --git a/NEWS b/NEWS
index 597156e..1c285c7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,394 @@
+Version 0.17.0
+
+ * C++20 modules support improvements:
+
+ - Named modules support in Clang, including automatic building of the
+ `std` and `std.compat` standard library modules from libc++ with Clang
+ 18 or later.
+
+ - Named modules support in MSVC, including automatic building of the `std`
+ and `std.compat` standard library modules.
+
+ Note: if combining the standard library modules importation with the
+ standard library headers inclusion, MSVC 17.10 or later is recommended.
+
+ - Modules support can now be enabled for any std.cxx value greater or
+ equal 20 (including `latest`).
+
+ - The "C++ Modules Support" section in the manual has been updated to
+ match the current state of the implementation.
+
+ * The `latest` and `experimental` cxx.std values are now mapped to C++26
+ from GCC 14 and Clang 18.
+
+ * The 23 and 2x c.std values are now mapped to /std:clatest starting from
+ MSVC 17.9. In particular, this option enables C23 typeof support.
+
+ * /Zc:preprocessor is now added for the `experimental` cxx.std value from
+ MSVC 17.9.
+
+ * New string_set buildfile value type.
+
+ This exposes the std::set<std::string> type to buildfiles.
+
+ New functions:
+
+ $size(<string-set>)
+
+ Subscript returns true if the value is present and false otherwise (so
+ it is mapped to std::set::contains()). For example:
+
+ set = [string_set] a b c
+
+ if ($set[b])
+ ...
+
+ Note that append (+=) and prepend (=+) have the same semantics
+ (std::set::insert()). For example:
+
+ set = [string_set] a b
+ set += c b # a b c
+ set =+ d b # a b c d
+
+ Example of iteration:
+
+ set = [string_set] a b c
+ for k: $set
+ ...
+
+ * New string_map buildfile value type.
+
+ This exposes the std::map<std::string,std::string> type to buildfiles.
+
+ New functions:
+
+ $size(<string-map>)
+ $keys(<string-map>)
+
+ Subscript can be used to look up a value by key. The result is [null] if
+ there is no value associated with the specified key. For example:
+
+ map = [string_map] a@1 b@2 c@3
+
+ b = ($map[b]) # 2
+
+ if ($map[z] == [null])
+ ...
+
+ Note that append (+=) is overriding (like std::map::insert_or_assign())
+ while prepend (=+) is not (like std::map::insert()). In a sense, whatever
+ appears last (from left to right) is kept, which is consistent with what
+ we expect to happen when specifying the same key repeatedly in a literal
+ representation. For example:
+
+ map = [string_map] a@0 b@2 a@1 # a@1 b@2
+ map += b@0 c@3 # a@1 b@0 c@3
+ map =+ b@1 d@4 # a@1 b@0 c@3 d@4
+
+ Example of iteration:
+
+ map = [string_map] a@1 b@2 c@3
+ for p: $map
+ {
+ k = $first($p)
+ v = $second($p)
+ }
+
+ While the subscript is mapped to key lookup only, index-based access can
+ be implemented (with a bit of overhead) using the $keys() function:
+
+ map = [string_map] a@1 b@2 c@3
+ keys = $keys($m)
+ for i: $integer_sequence(0, $size($keys))
+ {
+ k = ($keys[$i])
+ v = ($map[$k])
+ }
+
+ * New JSON buildfile value types.
+
+ New types:
+
+ json
+ json_array
+ json_object
+
+ New functions:
+
+ $json.value_type(<json>)
+ $json.value_size(<json>)
+ $json.member_{name,value}(<json-member>)
+ $json.object_names(<json-object>)
+ $json.array_size(<json-array>)
+ $json.array_find(<json-array>, <json>)
+ $json.array_find_index(<json-array>, <json>)
+ $json.load(<path>)
+ $json.parse(<text>)
+ $json.serialize(<json>[, <indentation>])
+
+ See "JSON Functions" in the manual for details.
+
+ For example, to load a JSON value from a file:
+
+ j = $json.load($src_base/board.json)
+
+ Or to construct it in a buildfile:
+
+ j = [json] one@1 two@([json] 2 3 4) three@([json] x@1 y@-1)
+
+ This can also be done incrementally with append/prepend:
+
+ j = [json_object]
+ j += one@1
+ j += two@([json] 2 3 4)
+ j += three@([json] x@1 y@-1)
+
+ Instead of using this JSON-like syntax, one can also specify valid JSON
+ input text:
+
+ j = [json] '{"one":1, "two":[2, 3, 4], "three":{"x":1, "y":-1}'
+
+ Besides the above set of functions, other handy ways to access components
+ in a JSON value are iteration and subscript. For example:
+
+ for m: $j
+ print $member_name($m) $member_value($m)
+
+ print ($j[three])
+
+ A subscript can be nested:
+
+ print ($j[two][1])
+ print ($j[three][x])
+
+ While a JSON value can be printed directly like any other value, the
+ representation will not be pretty-printed. As a result, for complex
+ JSON values, printing a serialized representation might be a more
+ readable option:
+
+ info $serialize($j)
+
+ * New json_map and json_set buildfile value types.
+
+ These expose the std::map<json_value,json_value> and std::set<json_value>
+ types to buildfiles.
+
+ New functions:
+
+ $size(<json-set>)
+ $size(<json-map>)
+ $keys(<json-map>)
+
+ Note that the $keys() function returns the list of map key as a json
+ array.
+
+ For example:
+
+ m = [json_map] 2@([json] a@1 b@2) 1@([json] 1 2)
+ s = [json_set] ([json] x@1 y@2) ([json] a@1 b@2)
+
+ print ($m[2][b]) # 2
+ print ($s[([json] y@2 x@1)]) # true
+
+ * New $first() and $second() functions which return the first and second
+ halves of a pair, respectively.
+
+ * New string functions:
+
+ $string.contains()
+ $string.starts_with()
+ $string.ends_with()
+ $string.replace()
+
+ See "String Functions" in the manual for details.
+
+ * New path functions:
+
+ $path.absolute()
+ $path.simple()
+ $path.sub_path()
+ $path.super_path()
+ $path.complete()
+ $path.try_normalize()
+ $path.try_actualize()
+
+ See "Path Functions" in the manual for details.
+
+ * New filesystem functions:
+
+ $filesystem.file_exists()
+ $filesystem.directory_exists()
+
+ See "Filesystem Functions" in the manual for details.
+
+ * Runtime/buildtime distinction when installing libraries.
+
+ Specifically, now, if a library is installed solely as a prerequisite of
+ an executable (potentially recursively), then only its runtime files are
+ installed omitting everything buildtime-related (static/import libraries,
+ non-versioned symlinks for shared libraries, pkg-config files, headers,
+ etc). If you are familiar with the runtime and -dev/-devel package splits
+ for libraries in Debian/Fedora, this is the analogous semantics.
+
+ * Support for extracting C and C++ predefined macros (predefs).
+
+ Specifically, the c and cxx modules now provide the c.predefs and
+ cxx.predefs submodules which can be loaded in order to register a rule
+ that generates a C or C++ header with the predefined compiler macros,
+ respectively. For details, refer to "C Compiler Predefined Macro
+ Extraction" and "C++ Compiler Predefined Macro Extraction" in the manual.
+
+ * Ability to serialize compilation/linking in C/C++ rules.
+
+ Specifically, both the C/C++ compile and link rules now recognize the
+ cc.serialize boolean variable which instructs them to compile/link
+ serially with regards to any other recipe.
+
+ This is primarily useful when compiling large translation units or linking
+ large binaries that require so much memory that doing that in parallel
+ with other compilation/linking jobs is likely to summon the OOM killer.
+ For example:
+
+ obj{memory-hog}: cc.serialize = true
+
+ * Ability to specify compiler mode options in a buildfile.
+
+ Now the configured mode options are appended to buildfile-specified (which
+ must be specified before loading the guess module).
+
+ In particular, this ability to specify the compiler mode in a buildfile is
+ useful in embedded development where the project may need to hardcode
+ options like -target, -nostdinc, etc. For example:
+
+ cxx.std = 20
+ cxx.mode = -target riscv32-unknown-unknown -nostdinc
+ using cxx
+
+ * New ~host-no-warnings and ~build2-no-warnings special configurations.
+
+ These are parallel to ~host and ~build2 but with suppressed C/C++ compiler
+ warnings.
+
+ Note also that the C++ ad hoc recipes are now by default built in
+ ~build2-no-warnings instead of ~build2 unless the project is configured
+ for development with config.<project>.develop=true.
+
+ * New {bin,c,cxx}.types submodules that only register target types.
+
+ This is primarily useful when providing custom C/C++ compilation/linking
+ rules.
+
+ * New -s|--timeout-success option in the `env` script builtin.
+
+ The semantics is equivalent to the --success option in the `timeout`
+ builtin.
+
+ * Ability to specify alternative sysroot for pkg-config files.
+
+ Specifically, the new config.cc.pkgconfig.sysroot variable provides
+ roughly equivalent functionality to PKG_CONFIG_SYSROOT_DIR in
+ pkg-config. For details and limitations, see "Rewriting Installed
+ Libraries System Root (sysroot)" in the manual for details.
+
+ * Ability to alias a target type from another project.
+
+ The syntax is:
+
+ define <type> = <proj-scope>/<type>
+
+ For example:
+
+ sdk_proj = ... # Root directory of the SDK.
+ define ldscript = $sdk_proj/ldscript
+
+
+ Additionally, unknown target types of imported targets are now aliased
+ automatically.
+
+ * New no_default_target attribute for source, buildfile import directives.
+
+ This attribute can be used to disable the default target semantics for the
+ sources/imported buildfile.
+
+ * Allow imported buildfiles to use config.* variables from own projects
+ (that is, the project from which the buildfile is imported).
+
+ * The fsdir{} targets are now usable in ad hoc recipes.
+
+ In particular, they can now be used to represent directory symlinks. For
+ example:
+
+ exe{hello}: ... fsdir{assets}
+
+ fsdir{assets}:
+ % update
+ {{
+ ln -s $src_base/assets $out_base/assets
+ }}
+ % clean
+ {{
+ rm $out_base/assets
+ }}
+
+ Likewise, file{} targets can now be used to represent file symlinks
+ created in ad hoc recipes.
+
+ * Ability to specify ad hoc recipes in separate files.
+
+ This can now be achieved with the new `recipe` directive:
+
+ recipe <language> <file>
+
+ Note that similar to the use of if-else and switch directives with recipes,
+ this directive requires explicit % recipe header. For example, instead of:
+
+ file{foo.output}:
+ {{
+ echo 'hello' >$path($>)
+ }}
+
+ We can now write:
+
+ file{foo.output}:
+ %
+ recipe buildscript hello.buildscript
+
+ With hello.buildscript containing:
+
+ echo 'hello' >$path($>)
+
+ Similarly, for C++ recipes (this time for a pattern rule), instead of:
+
+ [rule_name=hello] file{~'/(.+)\.output/'}:
+ % update clean
+ {{ c++ 1 --
+
+ --
+
+ ...
+
+ }}
+
+ We can now write:
+
+ [rule_name=hello] file{~'/(.+)\.output/'}:
+ % update clean
+ recipe c++ hello.cxx
+
+ With hello.cxx containing:
+
+ // c++ 1 --
+
+ --
+
+ ...
+
+ Relative <file> paths are resolved using the buildfile directory that
+ contains the `recipe` directive as a base.
+
+ Note also that this mechanism can be used in exported buildfiles with
+ recipe files placed into build/export/ together with buildfiles.
+
Version 0.16.0
* Support for Objective-C/C++ compilation.