| Age | Commit message (Collapse) | Author |
|---|
|
- in sequence containers, use operator[] instead of .at() when
accessing indices guaranteed to be in bound;
- in associative containers, prefer .find() and reusing the
returned const iterator to using .contains() and .at(); while
there, make any so obtained iterators const if they are read-only.
|
|
When backing up target-cache entries we use parallelism at two
dimensions, the independent cache entries and for each entry we
retrieve the artifacts in parallel. If for each dimension we use
the full amount of parallelism allowed, that gives a number of
threads up to the square of the amount of parallelism specified by
the user. Therefore, use in each dimension only the square root
of the allowed parallelism keeping the total parallelism (up to
rounding) within the specified range.
|
|
And ensure every user obtains HashFunction from corresponding IExecutionApi
|
|
|
|
|
|
! => not; && => and, || => or
|
|
...instead of not_null const ptr.
|
|
|
|
... for failures instead of the binary strict_logging. In this
way, we can log at log level Error in the serve instance, and for
the client at level Warning or Info, depending on whether failure
is expected (i.e., if targets are potentially taken from a serve
endpoint) or not.
|
|
After successful build of an export target target a cache entry is
written. As those export targets have a dependency structure, care
is taken to write them in correct order.
Writing a cache entry for an export target requires knowledge of
the analysis result of that target. Originally, all targets used
to be analysed locally, so that information was available for
every target that was not read from the local target cache already.
However, with the introduction of serve endpoints, it can happen
that a target was analyzed locally, but it depends on targets
obtained from serve. In this case, we have to refrain from writing
a target-level cache entry to keep the the consistency invariants
of the target-level cache.
|
|
When running in single node, serve endpoint should not even
consider sharding. Additionally, garbage collection uplinking
should also take the shard into account. For this purpose, a
TargetCache instance now remembers if it was explicitly sharded and
passed that information to the GarbageCollector for uplinking.
|
|
...by allowing a Logger instance to be provided. Also adds a flag
in order for failed artifacts from builds orchestrated by the serve
endpoint to be able to be reported as errors instead of warnings.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
We ensure that for each export target to be written to the target
cache all its implied export targets are written to the target
cache first. This ensures that the target cache maintains its
consistency at all times with respect to export target
dependencies.
|
|
...by specifying which TargetCache instance to use. This will allow
'just serve' to store target cache entries into the correct sharded
location.
|
|
|
|
|
|
|
