| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In particular, this can be used to make sure no other recipe is being
executed in parallel with the caller.
|
|
Fixes GH issue #361.
|
|
Fixes GH issue #362.
|
|
Fixes GH issue #365.
|
|
Fixes GH issue #368.
|
|
Fixes GH issue #366.
|
|
|
|
|
|
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
|
|
|
|
|
|
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
...
|
|
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.
|
|
|
|
|
