| Age | Commit message (Collapse) | Author |
|---|
|
... 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.
|
|
|
|
|
|
|
|
|
|
With the introduction of 'just serve', export targets can now be
built also independently from one another based on their
corresponding minimal repository configuration, as stored in the
target cache key.
In this context, this commit changes the RepositoryConfig usage
from one global (static) instance to pointers passed as necessary
throughout the code.
|
|
The install target, like any other target, has to have artifacts
and runfiles being proper stages, i.e., in such a way that the
keys can be interpreted as names in the file system without causing
conflicts. This property used to be unchecked, thus allowing users
to define mal-formed targets that, when used as inputs to actions,
would result in unspecified layout of the action directory. Fix
this by adding an appropriate check enforcing well-formedness of
the resulting stage.
|
|
|
|
The cache key for an export target should contain as target name
that of the export target (and its effective configuration) rather
than the exported target. As we computed the repository part of
the cache key for the target included in the key, this was still a
correct cache key except in the case an explicit file reference was
exported (as here, the information that the file was to be taken
rather than the target of the same name got lost). We still fix
this issue by making the implementation match our design (rather
than by including the file-reference bit in the cache key), as the
original design gives the cleaner protocol for target-level caching
as a service.
|
|
There is no need to use the full format API, so avoid increasing
the compile time gratuitously.
|
|
|
|
... to silence false-positive 'possible dangling reference'
warning produced by gcc 13.2.0.
|
|
|
|
While a foldl is enough to implement a reverse functionality,
adding it as a built in allows doing so in linear time.
|
|
... to obtain from a list of strings a map with those entries
as keys and true as value. In this way, repeated membership tests
in lists can be implemented more efficiently.
|
|
|
|
The rule generates a non-upwards symbolic link with given target
path.
|
