| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It turns out both target and group prerequisites can be replaced during
dependency synthesis in more obscure cases.
|
|
|
|
|
|
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.
|
|
|
|
|
|
This allows us to automatically get the target type-specific behavior
with regards to the out_only semantics (added in the previous commit)
instead of passing it explicitly from each call site.
|
|
|
|
|
|
|
|
|
|
|
|
While assigning null directly is unlikely, it's fairly easy via a variable
expansion. Real-world example:
./: exe{tensor}: include = $config.Eigen.unsupported
|
|
|
|
|
|
|
|
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.
|
|
Specifically, do not reduce typed RHS empty simple values for prepend/append
and additionally for assignment provided LHS is typed and is a container.
|
|
|
|
|
|
We used to backlink ad hoc group members both via the group and as individual
members. And for explicit groups it was done only via individual members,
which means it only works correctly if every member is individually updated.
Now both types of groups are backlinked from the group target.
|
|
|
|
Unlike normal and ad hoc prerequisites, a post hoc prerequisite is built
after the target, not before. It may also form a dependency cycle together
with normal/ad hoc prerequisites. In other words, all this form of dependency
guarantees is that a post hoc prerequisite will be built if its dependent
target is built.
See the NEWS file for details and an example.
|
|
Now unqualified variables are project-private and can be typified.
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
Allowing this seems harmless since all the alias does is pull its
prerequisites. And they are handy to use as metadata carriers.
|
|
Note that we started with this semantics but it was changed in a commit on
2021-09-16 for reasons not entirely unclear but most likely due to target-
specific variables specified for the group not being set on all the members.
Which we have now addressed (see the previous commit).
Note also that this new (old) semantics is not without its own drawbacks.
Specifically, there is a bit of waste when the target-specific variable is
really only meant for the recipe and thus setting it on all the members is
unnecessary. For example:
<{hxx ixx cxx}{options}>: cli{options}
{
options = ...
}
{{
# Use options.
}}
But this feels like a quality of implementation rather than conceptual
issue. For example, we could likely one day address it by synthesizing a
separate group target for ad hoc groups.
|
|
In particular, we now have separate auxiliary data storage for inner
and outer operations.
|
|
|
|
|
|
|
|
A rule hint is a target attribute, for example:
[rule_hint=cxx] exe{hello}: c{hello}
Rule hints can be used to resolve ambiguity when multiple rules match the same
target as well as to override an unambiguous match.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Our current semantics is to clean any prerequisites that are in the same
project (root scope) as the target and it may seem more natural to rather only
clean prerequisites that are in the same base scope. While it's often true for
simple projects, in more complex cases it's not unusual to have common
intermediate build results (object files, utility libraries, etc) reside in
the parent and/or sibling directories. With such arrangements, cleaning only
in base (even from the project root) may leave such intermediate build results
laying around (since there is no reason to list them as prerequisites of any
directory aliases). So we clean in the root scope by default but now any
target-prerequisite relationship can be marked not to trigger a clean with the
clean=false prerequisite-specific value.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now triple dot and escape sequence can appear almost anywhere in the target
name (see target::split_name() for details).
|
|
|
|
|
|
Also fix a similar assertion.
|
|
|
