| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
...instead of filling in a map passed from the outside.
|
|
|
|
...that is to be used by FileRoot::ToArtifactDescription.
|
|
...in async map instances, same as for reporting cycles.
This removes the restriction that the key object has to posses the
ToString method, allowing it to be used, e.g., with just-mr maps.
The now obsolete HasToString concept is removed.
|
|
When switching from a target to the artifacts that are the inputs
of a particular action, the provides map is also switched to provide
additional (besides the inputs) information about the action, in
particular the command. Extend this provides map with the remaining
information, in particular the working directory.
|
|
|
|
...instead of using singleton calls.
|
|
|
|
...to track changes during refactoring easier.
|
|
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.
|
|
... by taking the correct map to report which targets failed
to be analysed and also report about rules that failed to be
analysed.
|
|
... in a structured way to eventually support machine-readable access to
the identifiers of the log files.
|
|
|
|
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.
|
|
...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
|
|
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.
|
|
|
|
... 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.
|
|
|
|
Similarly to the jobs common argument, we can simply only pass the
needed single element from the analysis arguments struct. This will
allow for a clearer understanding of what target analysis requires
and reduce the overhead when reutilizing this method in just serve.
|
|
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.
|
|
|
|
This feature has been introduced with C++20.
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
... while technically not required, it makes it harder to
run into nasty errors.
|
|
... to be able to report the respective graph for later analysis
by other tools.
|
|
Analysing a target is a pretty self-contained task. So move it
into a library of its own, to keep main.cpp more managable.
|
