| Age | Commit message (Collapse) | Author |
|---|
|
The built-in rule "tree" does not support the field "data". Hence
remove it from the list of white-listed fields so that an appropriate
warning is issued if it occurs for that rule.
(cherry-picked from 1324f45fa7b1938b39854f7b38d981c238da2fbc)
|
|
|
|
|
|
While reporting an origin target with action number within that
target describes an action uniquely in a way meaningful to the
user, it might not always be eay to unserstand which precise action
is currently running. For example, for a library with many source
files, we have a target generating a large number of actions and
the association of source file to action number requires detailled
knowledge of the build description. The name of the primary ouput
of that action, on the other hand immediately identifies the file
that is compiled. Therefore, report this as well.
|
|
... and use it when normalizing the origins of actions. For this
task, any well-defined linear order is sufficient. Using a native
comparision (rather than comparing the canonical serialisation)
significantly speeds up that normalisation process, as the assumption
that it would be rare that an action has more than one origin turned
out to be false. In fact, we have seeen cases where this sorting
used to take several seconds before this change, so that this change
reduced analysis time by more than a factor of 5.
|
|
The "generic" rules deliberately resolves conflicts on identical
paths in a latest-wins fashion (seeing all artifacts as later than
all runfiles) to allow an easy way to define actions. However, the
inputs stage obtained by this resolution can still contain conflicts
and those are an error. Properly detect those. Also clarify in the
documentation, that only conflicts on identical paths are resolved
in the described priority, not semantic overlap.
|
|
|
|
|
|
Requires the use of a pragma to avoid wrong removal suggestion for
path_hash.hpp.
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
|
|
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
|
|
|
|
...and private members using lower_case_
|
|
...since we use recursion for trees a lot, but skip this check manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... to avoid regressing there. To be able to enable these
checks also disable a false positive.
|
|
|
|
|
|
...to get the protocol type.
|
|
...with ArtifactDigestFactory::HashDataAs
|
|
... while keeping our .clang-format file.
|
|
|
|
... and also perform conflict check on the normalized paths. Still,
the the output of the "ACTION" funtion be keyed by the representation
of the paths as originally described, to allow the author of a rule
to use non-normalized paths as well.
|
|
... and, in particular, do not include headers of other libraries
that are not even needed.
|
|
! => not; && => and, || => or
|
|
While our local action execution implicitly creates the specified
cwd with the first output file or directory, this behaviour is
not mandated by the remote-execution protocol. There, an action
definition has to ensure that cwd is a directory implied by the
input files. Achieve this, by adding an empty input directory
at cwd if this can be done without creating tree conflicts.
|
|
|
|
|
|
... for the working directory inside the action directory.
|
|
|
|
|
|
|
|
|
|
|
|
...to track changes during refactoring easier.
|
|
...instead of unobvious ctors relying on overload resolution.
|
|
...and adjust AnalyseContext.
|
|
|
|
|
|
Most built-in rules are just described by their name, assuming they
are known to the user anyway. One exception, however, are "export"
targets, as those serve as interfaces to (logical) repositories and
hence is supposed to have a documentation of the target itself. Over
time, however, "configure" targets have evolved to become internal
interfaces (maybe even for an external target), e.g., to provide
default values and hence make better use of the actual export target.
Therefore it is desirable to provide a bit more information when
asked to describe a "configure" target.
- As "configure" targets have a fixed set of keys, adding a "doc"
field is a conservative extension; this can be useful to give an
overview what the target is about.
- An important information of a "configure" target is the target
that is configured. While this, in general, is an expression, in
the typical cases, the description is very short (a literal target
name, or a variable). So we can afford to show the definition.
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
|
|
...to track changes during refactoring easier.
|
