| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Also clarify the target_decl documentation.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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>
|
|
|
|
|
|
|
|
Now, when matching a rule, the caller may request a subset of the full
functionality of performing an operation on a target. This is achieved
with match options.
|
|
|
|
|
|
|
|
|
|
|
|
This makes it consistent with the existing ad hoc rules semantics.
|
|
|
|
|
|
|
|
|
|
|
|
Specifically:
1. New --dump-format option. Valid values are `buildfile` and `json-v0.1`.
2. The --dump option now recognizes two additional values: `match-pre` and
`match-post` to dump the state of pre/post-operations. The `match` value
now only triggers dumping of the main operation.
|
|
|
|
|
|
Similar to line continuations, that would make directory paths on Windows
unusable, for example:
b info(C:\myproj\)
Note that while this is less of a problem in command line variable overrides,
we disable it there for consistency.
|
|
Line continuations would make directory paths on Windows unusable, for
example:
b C:\myproj\
|
|
Also make effective escaping in buildspec and command line variable overrides
consistent with double-quoted strings.
|
|
|
|
Specifically:
1. In the double-quoted strings we now only do effective escaping of the
special `$("\` characters plus `)` for symmetry.
2. There is now support for "escape sequence expansion" in the form $\X where
\X can be any of the C/C++ simple escape sequences (\n, \t, etc) plus \0
(which in C/C++ is an octal escape sequence). For example:
info "foo$\n$\tbar$\n$\tbaz"
Will print:
buildfile:1:1: info: foo
bar
baz
|
|
Specifically, do not reduce typed RHS empty simple values for prepend/append
and additionally for assignment provided LHS is typed and is a container.
|
|
This is relied upon by the parser to provide conversion/concatenation
semantics consistent with untyped values. Note that we handle NULL values
only for types that have empty representation.
|
|
|
|
There are three options here: we can "fall through" to an outer scope (there
is always the global scope backstop; this is the old semantics, sort of), we
can return NULL straight away, or we can fail. It feels like in most cases
unknown scope or target is a mistake and doing anything other than failing is
just making things harder to debug.
|
|
|
|
|
|
|
|
In particular, we now always print error message on non-0 exit except
in cases where such exit is ignored.
|
|
|
