| Age | Commit message (Collapse) | Author |
|---|
|
|
|
While reporting an origin target with action number within that
target describes an action uniquely in a way meaningful to the
user, it might not always be eay to unserstand which precise action
is currently running. For example, for a library with many source
files, we have a target generating a large number of actions and
the association of source file to action number requires detailled
knowledge of the build description. The name of the primary ouput
of that action, on the other hand immediately identifies the file
that is compiled. Therefore, report this as well.
|
|
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
|
|
|
|
...by allowing a Logger instance to be provided.
|
|
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.
|
|
... with two minor code base changes compared to previous
use of gsl-lite:
- dag.hpp: ActionNode::Ptr and ArtifactNode::Ptr are not
wrapped in gsl::not_null<> anymore, due to lack of support
for wrapping std::unique_ptr<>. More specifically, the
move constructor is missing, rendering it impossible to
use std::vector<>::emplace_back().
- utils/cpp/gsl.hpp: New header file added to implement the
macros ExpectsAudit() and EnsureAudit(), asserts running
only in debug builds, which were available in gsl-lite but
are missing in MS GSL.
|
|
|
|
|
|
|
|
While there, also add all direct dependencies explicitly; using
directly dependencies that are pulled in only indireclty causes
problems from a maintainability point of view.
|
|
|
|
For a user, an important information is to know which actions
are currently running and, more importantly, the target that
caused them. To do so, we need a bit of infrastructure.
- We have to keep track of begin and end of running actions,
as well as the order in which they were started. That has
to happen efficiently and in a thread-safe way.
- We have to compute and keep the origin map for actions,
even if we don't serialize the action graph.
|
|
Reporting, with exponentially backing off intervals, the number of
cache hits found so far, the number of actions that have ben run,
and the number of actions currently under consideration.
|
