| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 lookup 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])
}
Also, this commit changes the naming of other template-based value types (not
exposed as buildfile value types) to use C++ template id-like names (e.g.,
map<string,optional<bool>>).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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), 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Feels like this is an equivalent context to subscript/iteration.
|
|
This in fact feels more natural in the "for consumption" model and also helps
with the nested subscript semantics.
|
|
|
|
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>])
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In particular, this used to prevent file_rule from match such targets
for clean.
|
|
|
|
This attribute can be used to disable the default target semantics for the
sources/imported buildfile.
|
|
|
|
|
|
|
|
|
|
The syntax is:
define <type> = <scope>/<type>
|
|
|
|
|
|
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.
|
|
|
|
|
|
With -frewrite-includes Clang has issues with correctly tracking location
information (manifests itself as wrong line numbers in debug info, for
example). The result also appears to reference the .Si file instead of the
original source file for some reason.
While at it also omit trying to scan such files since that can be hazardous
(such files sometimes use `#`-style comments).
|
|
|
|
|
|
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 things
like -target, -nostdinc, etc. For example:
cxx.std = 20
cxx.mode = -target riscv32-unknown-unknown -nostdinc
using cxx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See comment for the long-term plan.
|
|
|
