| Age | Commit message (Collapse) | Author |
|---|
|
|
|
... also, gracefully handle the case of a missing working
directory when determining the current module, falling back
to the top-level module.
(cherry-picked from 3a5da87b7185c49567da97cd829733f9bb653b44)
|
|
|
|
|
|
|
|
|
|
... and set default stack size to 8 MB.
(cherry picked from commit 9e45d1525b0fde12a08f7c376b5bf2c7bfbc9803)
|
|
|
|
|
|
|
|
...caused by incorrectly setting and resetting the library internal
state and the misuse of pthreads in libgit2.
Normally, git_libgit2_init and git_libgit2_shutdown should span the
life of a worker thread in order to be safely used. However, due to
an incorrect implementation of libgit2's threadstate with pthreads,
on unix systems there is a race condition.
Until the use of pthread_key_t is corrected in libgit2, we need to
apply a workaround by always ensuring that the main thread is the
first thread reaching the GitContext constructor.
|
|
|
|
... 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.
|
|
|
|
... by including the details of the parse error.
|
|
... asking just to transfer everyting installed to the local CAS first.
|
|
... to avoid unnecessary downloads and hence speed things up.
|
|
|
|
By default, messages at level "progress" and above are shown. So,
messages at that level should be useful for the user in the typical
case. For the count of export targets, this information is only useful
if the build involves export targets at all; the absence of export
targets is typically only used when debugging the build structure.
|
|
The improved GC implementation uses refactored storage
classes instead of directly accessing "unknown" file paths.
The required storage class refactoring is quite substantial
and outlined in the following paragraphs.
The module `buildtool/file_system` was extended by:
- `ObjectCAS`: a plain CAS implementation for
reading/writing blobs and computing digests for a given
`ObjectType`. Depending on that type, files written to the
file system may have different properties (e.g., the x-bit
set) or the digest may be computed differently (e.g., tree
digests in non-compatible mode).
A new module `buildtool/storage` was introduced containing:
- `LocalCAS`: provides a common interface for the "logical
CAS", which internally combines three `ObjectCAS`s, one
for each `ObjectType` (file, executable, tree).
- `LocalAC`: implements the action cache, which needs the
`LocalCAS` for storing cache values.
- `TargetCache`: implements the high-level target cache,
which also needs the `LocalCAS` for storing cache values.
- `LocalStorage`: combines the storage classes `LocalCAS`,
`LocalAC`, and `TargetCache`. Those are initialized with
settings from `StorageConfig`, such as the build root base
path or number of generations for the garbage collector.
`LocalStorage` is templated with a Boolean parameter
`kDoGlobalUplink`, which indicates that, on every
read/write access, the garbage collector should be used
for uplinking across all generations (global).
- `GarbageCollector`: responsible for garbage collection and
the global uplinking across all generations. To do so, it
employs instances of `LocalStorage` with `kDoGlobalUplink`
set to false, in order to avoid endless recursion. The
actual (local) uplinking within two single generations is
performed by the corresponding storage class (e.g.,
`TargetCache` implements uplinking of target cache entries
between two target cache generations etc.). Thereby, the
actual knowledge how data should be uplinked is
implemented by the instance that is responsible for
creating the data in the first place.
|
|
|
|
|
|
google::longrunning::Operations::GetOperation
For each action that is executed, an entry is added to a shared thread
safe cache. Once the number of operations stored exceeds twice 2^n,
where n is given by the option --log-operations-threshold, at most 2^n
operations will be removed, in a FIFO scheme.
|
|
... instead of only honoring the latest argument. In this way,
standard overlays coming from the launcher configuration can be
amended in individual invocations.
|
|
|
|
|
|
|
|
..., i.e., the requirement that the positional arguments form a
syntactically valid target name. An explicit error message (created
by the target-name parsing) is preferrable over tacitly dropping all
but the last up to two arguments (which is the meaning of CLI11's
expected(2)).
While there, drop duplicate full stop in error message.
|
|
This subcommand starts a single node remote execution service honoring
the just native remote protocol.
If the flag --compatible is provided, the execution service will honor
the original remote build execution protocol.
New command line args supported by this subcommand:
-p,--port INT: Execution service will listen to this port. If unset,
the service will listen to the first available one.
--info-file TEXT: Write the used port, interface, and pid to this file
in JSON format. If the file exists, it will be overwritten.
-i,--interface TEXT: Interface to use. If unset, the loopback device
is used.
--pid-file TEXT Write pid to this file in plain txt. If the file
exists, it will be overwritten.
--tls-server-cert TEXT: Path to the TLS server certificate.
--tls-server-key TEXT: Path to the TLS server key.
Co-authored by: Klaus Aehlig <klaus.aehlig@huawei.com>
|
|
|
|
|
|
|
|
|
|
... dumping only the configured targets that are export targets.
Those targets are of particular interest as those are the targets,
as they are the high-level caching points and also often serve
as interface between projects.
|
|
|
|
|
|
|
|
Compared to the previous commit, the action graphs for just
and its unit tests are unchanged.
- Git hash of action graph for ["",""]:
c6e75f17abd7ffaab6ff9bb725ad67ec0bf6c973
- Git hash of action graph for ["test/buildtool","TESTS"]:
8063dfb3dd7daa9ae01d95c177e14946f785c57e
Refactor:
- "local cflags" to "private-cflags"
- "local defines" to "private-defines"
- "link externals" to "private-ldflags"
- "deps" to "private-deps" for (test) binaries
- "proto" to "private-proto" for binaries
Improvements:
- consistent variable declaration order:
OS, ARCH, HOST_ARCH, TARGET_ARCH,
CC, CXX, CFLAGS, CXXFLAGS, ADD_CFLAGS, ADD_CXXFLAGS,
AR, ENV, PATH
- use fields close to their definition (in RULES)
- use common expression for binaries and test binaries
- split expression "flags" and "compiler"
... to separate ones for CC and CXX.
- rename "transition" to "deps-transition"
... to avoid conflicts with other transitions.
- support "defaults-transition" for CC expressions
Implement:
- "cflags" for libraries
- "private-cflags" for (test) binaries
- "private-defines" for test binaries
- "private-ldflags" for test binaries
- (public) "defines" for libraries
|
|
|
|
... with the order for "field_doc" being taken from
"string_fields", "target_fields", and "config_fields"
(in that order). For "config_doc", the order is taken
from the "config_vars" list. Thus, being consistent with
the (non-JSON) pretty printing of rules.
|
|
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.
|
|
|
|
Add an option --dump-vars showing the variables of the configuration
used (including the use of them being unset). This information can
be used, e.g., to export a given target in a maximally flexible way.
|
|
|
|
... if none is specified on command line or in the config.
|
|
|
|
Before this change, TargetResults that appear inside of
other TargetResults (typically via value nodes) were
serialised via the top-level serialisation function for
TargetResults. While technically correct, it is rather
inefficient as identical expressions from outer and inner
TargetResults are not properly deduplicated and a deeply
nested data structure is maintained.
With this change, expressions of inner TargetResults are
serialised in the context of outer TargetResults, resulting
in a flat list of all transitively contained expressions
with proper deduplication applied.
As this serialisation of TargetResult is used in
target-level cache entries, the new format is a breaking
change to existing entries. Therefore, after switching to
the new serialisation format introduced by this commit,
users are required to clean their target-level cache.
This also reverts commit d22adef666d704680ee74b35a46d530f6b6d5f15,
"Recursively scan provided results for known artifacts".
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
|
|
... while technically not required, it makes it harder to
run into nasty errors.
|
