| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
|
|
|
|
|
|
Also fix bug in out clearing.
|
|
x [...], for x [...])
|
|
|
|
|
|
|
