| Age | Commit message (Collapse) | Author |
|---|
|
... 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.
|
|
... to 320 chars for the configuration to keep error messages managable
in case of heavy configurations (e.g., generated internally by a complex
configure target).
|
|
... to keep error messages more readable.
|
|
Possibly empty directory path should be escaped.
|
|
... of an absent target. Here, the request is given by repository
root and filename; so the filename is to be taken relative to the
root, i.e., we have to prefix the targets-file name with the module.
|
|
While this can already be expressed by an "if" statement, having
a dedicated function for logical negation makes some expressions
more readable.
|
|
... using, also for the "then" branch, the empty list as default.
In this way, this statement not only more symmetric, but also
allows shorter representations of some typical expressions.
|
|
Lists are somtimes used in configurations as replacement for tuples.
Providing length gives an easy way to detect usage errors.
|
|
|
|
Commit f5f9be5bc07b16807aceac86fba9212e3889762a changed from
tracking progress by cache key to tracking by configured target;
however, the absent-target map was forgotten. Fix this while also
switching to the shortend export-target representation introduced
in the previous commit.
|
|
As we always analyse export targets in their canonical configuration (and
do count in the progress the mapping from obtained configuraiton
to canonical one), the shortend name (i.e., the representation
with null values dropped form the configuration) is still a unique
representation of the target. Use this in progress reporting to
simplify reading the progress sample.
|
|
|
|
... in a structured way to eventually support machine-readable access to
the identifiers of the log files.
|
|
... in logger extension.
|
|
Configured targets, by design, cannot distinguish between a value
not occuring in the configuration and occuring there with value
null. Therefore, to understand the conflict, we can as well drop
all the null values of the target configuration when reporting it.
|
