| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Enable performance-enum-size check.
|
|
...proposed by clang-tidy.
Enable bugprone-optional-value-conversion check.
|
|
|
|
|
|
... to avoid regressing there. To be able to enable these
checks also disable a false positive.
|
|
|
|
|
|
...to get the protocol type.
|
|
...that is to be used by FileRoot::ToArtifactDescription.
|
|
... depending on the evaluation order implicit in the compiler.
|
|
|
|
...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.
|
|
Originally, the expression lanuage only contained a function to
deduplicate a list, keeping only the right-most occurence. The
reason was that this is the order needed for linking: a library
providing an open symbol has to come on the command line after the
library using that symbol (and hence making it an open symbol).
However, by now use cases have emerged that require a topological
sorting where definition comes before use; also, when composing
the value of PATH from fragments, we usually want to keep the first
occurrence in order for it to take precedence. Therefore, also
add "nub_left" as built-in function, allowing a more condense (and
slightly more efficient) description in rules instead of the
revserse-nub_right-reverse pattern.
|
|
... and, in particular, do not include headers of other libraries
that are not even needed.
|
|
! => not; && => and, || => or
|
|
... allowing to select only the keys in a specific subdir,
and move the them to top-level.
|
|
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.
|
|
Since c++17 the 'explicit' keyword has use also for constructors
with more than one argument and it is recommended to use it by
default whereever implicit conversions are not expected bahaviour.
|
|
|
|
|
|
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.
|
|
...to track changes during refactoring easier.
|
|
...to use corresponding Storage for storing auxiliary information.
|
|
... to allow generating symlinks as part of a rule, as it is already described
in our documentation.
|
|
Once a RepositoryConfig instance gets populated, it must never be
changed again. Therefore, all functions accepting these instances
should only take them as pointers to const.
|
|
If the serve endpoint reports an internal error, local builds
should not continue and the error message should be provided.
Similarly, if the serve endpoint promises the target cache value to
be in remote CAS, but the client cannot find or process it as
needed, then a local build again should not continue and the reason
be provided as an error message.
|
