| 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.
|
|
... 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.
|
|
...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.
|
|
... 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.
|
|
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.
|
|
... with only the non-null entries of the configuration. This
information is enough for the user to build this target, e.g.,
when searching for the cause of a build failure.
|
|
|
|
|
|
|
|
Mentioning in particular the involved artifacts as well as the direct
dependencies that brought them in. Here, we are in a simple situation
as all built-in rules that check conflicts only use artifacts and
runfiles of their dependencies, but not the provided data.
Also, the built-in rules that check staging conflicts do not do
configuration transitions, hence it is enough to show the target
name of the dependencies containing the artifact if for the built-in
target we show the configuration.
|
|
Main culprits:
- std::size_t, std::nullptr_t, and NULL require <cstddef>
- std::move and std::forward require <utility>
- unordered maps and sets require respective includes
- std::for_each and std::all_of require <algorithm>
|
|
For an absent export target, the first step of analysis is to ask
serve for the flexible variables. The answer to this request is,
however, independent of the configuration for this target. So we
can avoid calls by caching the answer in an additional map.
|
|
For export targets, we know ahead of time the effective configuration;
so, if the current configuration is not the effective anyway, we
can simply analyse the effective configuration and take that result.
In this way, we can avoid calls to serve if a target is analysed
in two configurations that coincide on the flexible variables.
|
|
For export targets, we know ahead of time the effective configuration;
so, if the current configuration is not the effective anyway, we
can simply analyse the effective configuration and take that result.
As a side effect, we also count the number of observed export
targets correctly.
|
|
...by increasing granularity in client-side reporting. This allows
to correctly continue with builds of local targets if the serve
endpoint does not have the requested target, as well as improve
the reporting for users on failure.
|
|
...by allowing a Logger instance to be provided.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
... with effective config instead of the actual cache key, which
is simply a blob identifier that is probably not so meaningful for
the user watching the build.
|
