| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>>).
|
|
|
|
|
|
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)
|
|
|
|
|
|
This is used by bpkg to detect forwarded configurations without incurring
the full context creation overhead.
|
|
Based on patch by Matthew Krupcale.
|
|
|
|
Specifically, do not reduce typed RHS empty simple values for prepend/append
and additionally for assignment provided LHS is typed and is a container.
|
|
|
|
|
|
Now unqualified variables are project-private and can be typified.
|
|
We have patterns only for the public variables pool.
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
|
|
Specifically, now we can do:
x = [uint64] 0x0000ffff
cxx.poptions += "-DOFFSET=$x" # -DOFFSET=65535
cxx.poptions += "-DOFFSET=$string($x, 16)" # -DOFFSET=0xffff
cxx.poptions += "-DOFFSET=$string($x, 16, 8)" # -DOFFSET=0x0000ffff
Note that there is no hex notation support for the int64 (signed) type.
|
|
|
|
The reset on each modification semantics is used to implement the default
value distinction as currently done in the config module but later probably
will be done for ?= and $origin().
|
|
|
|
Note that the unmatch (match but do not update) and match (update during
match) values are only supported by certain rules (and potentially only for
certain prerequisite types).
Additionally:
- All operation-specific variables are now checked for false as an override
for the prerequisite-specific include value. In particular, this can now be
used to disable a prerequisite for update, for example:
./: exe{test}: update = false
- The cc::link_rule now supports the update=match value for headers and ad hoc
prerequisites. In particular, this can be used to make sure all the library
headers are updated before matching any of its (or dependent's) object
files.
|
|
|
|
|
|
|
|
|
|
This is in addition to the already supported path-based target type/pattern
specific variables. For example:
hxx{*}: x = y # path-based
hxx{~/.*/}: x = y # regex-based
|
|
Also improve conversion diagnostic.
|
|
|
|
|
|
|
|
|
|
|
|
Seeing that std::map is becoming a common Buildfile variable type.
|
|
|
|
|
|
|
|
|
|
|
|
While we could automatically set it if the target is imported, there is
nothing we can do if the target is used in the same project. So to avoid
confusion we make it mandatory.
|
|
|
|
Also deduce the recipe name.
|
|
|
|
|
|
Value subscript is only recognized in evaluation contexts (due to ambiguity
with wildcard patterns; consider: $x[123].txt) and should be unseparated from
the previous token. For example:
x = ($y[1])
x = (($f ? $y : $z)[1])
x = ($identity($y)[$z])
|
|
|
|
|
