| Age | Commit message (Collapse) | Author |
|---|
|
... 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.
|
|
... 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.
|
|
|
|
|
|
|
|
... which are, in particular, artifacts involved in staging conflicts.
While there, also make disjoint union honor the expression log limit.
|
|
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.
|
|
To avoid too many intermediate results, we compute the union of
a list in a divide and conquer fashion. Of course, for a disjoint
union, the recursive calls on the lists of half the length have to
be disjoint as well, i.e., the template parameter kDisjoint has to
be passed on. Fix this.
|
|
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>
|
|
Numerical values are used at some places in justbuild: as value for
timeout scaling, as well as by the "range" expression that is used,
e.g., to define repreated test runs. Therefore, improve support
for numerical values by adding basic operations.
|
|
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.
|
|
... instead of blindly assuming the evaluation succeeds.
Co-authord-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
During analysis it is useful to track and report the progress for
all export targets. This is not exclusively linked to a serve
endpoint being present, despite most of the time being expected to
be spent in export targets being served from the remote endpoint.
This commit refactors the current implementation to give proper
feedback to the user on the progress of the analysis phase.
|
|
|
|
...with regular instances that have controlled life-times.
This avoids race conditions in tracking and reporting the results
of analysis and build, as the serve endpoint can orchestrate
multiple builds at the same time asynchronously. As a bonus
side-effect this also ensures the correctness of the progress
reporting per orchestrated build.
|
|
The serve endpoint always has to access the correctly sharded
target cache, including during analysis. For this purpose, the
target cache instance interrogated during analysis has to be
explicitly provided.
|
|
|
|
|
|
|
|
... to provide an informative error message on how a rule is related
to a particular import and, in particularly, at which expression
a problem with the import occurred.
While there, also improve the message in the other error case to
follow our standard line-breaking scheme.
|
|
By showing the full entity name and also adding the usual
newline character after every "While ..." clause.
|
|
|
|
... instead of erroring on missing file. In this way, whenever a
rule or expression from an absent root would have to be read, we
get a meaningful error message and not a complaint about a file
not being there.
|
|
|
|
Also cleans up the logging when parsing the serve service
configuration file.
|
|
... that are eligible for caching. In this way, we can accurately keep
track of the dependencies between target-level cache entries. Note
that it is enough to track the export targets eligible for caching,
as no target depending on an ineligible export target can be eligible.
|
|
|
|
While in our setting, a missing directory is generally OK, it is
not OK to ask for the content of an absent root. In particular, we
should not assume it to be empty, just because the root is absent.
|
|
As we already have a good enough API call and in order to improve
specificity in log messages, there is no need for one more level of
abstraction. This will also make it easier to drop in the future
this check (if deemed unnecessary anymore), while keeping in place
the mandatory check that a serve endpoint has been configured.
|
|
|
|
|
