| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
See GCC bugs 107532, 110213.
|
|
|
|
|
|
This makes it consistent with the existing ad hoc rules semantics.
|
|
|
|
|
|
|
|
This is used by bpkg to detect forwarded configurations without incurring
the full context creation overhead.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
This should also get rid of the bogus -Wdangling-pointer issued by GCC 12.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
The warning is issued inside the target_lock's move constructor so we
sidestep the whole thing by avoiding the call to the move constructor.
|
|
|
|
These options can be used to understand which dependency chain causes matching
or execution of a particular target.
|
|
In particular, we now have separate auxiliary data storage for inner
and outer operations.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
The old half-way semantics of execute() wasn't useful.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An ad hoc pattern rule consists of a pattern that mimics a dependency
declaration followed by one or more recipes. For example:
exe{~'/(.*)/'}: cxx{~'/\1/'}
{{
$cxx.path -o $path($>) $path($<[0])
}}
If a pattern matches a dependency declaration of a target, then the recipe is
used to perform the corresponding operation on this target. For example, the
following dependency declaration matches the above pattern which means the
rule's recipe will be used to update this target:
exe{hello}: cxx{hello}
While the following declarations do not match the above pattern:
exe{hello}: c{hello} # Type mismatch.
exe{hello}: cxx{howdy} # Name mismatch.
On the left hand side of `:` in the pattern we can have a single target or an
ad hoc target group. The single target or the first (primary) ad hoc group
member must be a regex pattern (~). The rest of the ad hoc group members can
be patterns or substitutions (^). For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
On the left hand side of `:` in the pattern we have prerequisites which can
be patterns, substitutions, or non-patterns. For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} hxx{^'/\1/'} hxx{common}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
Substitutions on the left hand side of `:` and substitutions and non-patterns
on the right hand side are added to the dependency declaration. For example,
given the above rule and dependency declaration, the effective dependency is
going to be:
<exe{hello} file{hello.map>: cxx{hello} hxx{hello} hxx{common}
|
|
|
|
|
|
|
|
|
|
|
|
|
