| 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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
While assigning null directly is unlikely, it's fairly easy via a variable
expansion. Real-world example:
./: exe{tensor}: include = $config.Eigen.unsupported
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This functionality is enabled with the depdb-dyndep --dyn-target option. Only
the make format is supported, where the listed targets are added as ad hoc
group members (unless already specified as static members). This functionality
is not available in the --byproduct mode.
|
|
Based on patch by Matthew Krupcale.
|
|
|
|
|
|
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.
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
|
|
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.
|
|
|
|
For example, this allows a Qt moc rule not to list generated headers
from libQtCore since they are pre-generated by the library.
|
|
|
|
|
|
In particular, we now have separate auxiliary data storage for inner
and outer operations.
|
|
|
|
|
|
|
|
|
|
Instead of overriding this function, derived targets must now set the
dynamic_type variable to their static_type in their constructor body.
|
|
|
|
In particular, the match() rename makes sure it doesn't clash with
rule::match() which, after removal of the hint argument in simple_rule,
has exactly the same signature, thus making it error-prone to calling
recursively.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
