| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
Specifically, both the C/C++ compiler and link rules now recognize the
cc.serialize boolean variable which instructs them to compiler/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
|
|
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>
|
