| Age | Commit message (Collapse) | Author |
|---|
|
... by the requested subcommand. In particular, do not set it for
pure analyse requests.
|
|
|
|
|
|
|
|
|
|
|
|
This will make it available also to just.
|
|
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>
|
|
|
|
...also for 'analyse' and 'describe'.
|
|
|
|
... as, for absent repositories, we need to get the description from
the serve end point. As a consequence, also support -r and --compatible,
as the remote-execution endpoint needs to fit with the one for the
serve endpoint.
|
|
... as even this command now adds entries to CAS, e.g., the shard
for the target-level cache. Also, this command block gc by keeping
a lock (also in the local build root).
|
|
While just-mr does not use remote-execution properties, it is
still useful to have those as a separate entry in the rc file. With
rc-file delegation, this gives committed rc files an easy way to
specify the image to be used without having to set all the remaining
arguments for the various just subcommands in "just args".
|
|
|
|
|
|
When just-mr acts as a launcher, for most subcommand options the
"just args" entry in the rc files provides a convenient way to set
them. However, some options take a file as argument; for those it can
be desirable to set them without assuming a fixed file-system layout
and instead refer to logical roots, in particular the work space.
for the ones that refer to files, it is often desirable to have a potential
reference to the work space. Add this functionality.
|
|
|
|
This is required in order to make them available to 'just serve'
in a minimal just installation.
|
|
... by also keeping the map of commit to tree locally.
|
|
This better separates the utility methods used in just-mr commands
and avoids any cyclic dependencies that might arise in new utility
methods requiring both existing utilities and the command-line
arguments.
|
|
These have similar meanings as in 'just', are forwarded to 'just'
subcommands that support them, and can be set also in the RC file
via appropriate fields.
|
|
...by moving subcommands code into separate libraries.
This maintains a cleaner code structure and lowers the build time
by improving target caching.
|
|
|
|
Moves away from literal strings in the async maps.
|
|
This feature has been introduced with C++20.
|
|
Make just-mr unconditionally support an option -D that collects a
configuration overlay and forwards it to the invocation of a just
subcommand that supports this option. This syntax-switching facility
makes it easy to embedd dynamic parts of the configuration (like
the head commit to be part of a version string) as those information
can unconditionally be the first argument to just-mr.
|
|
In this way, we have the whole layout of the local build root
consolidated in one place. Moreover, in this way, the location
of the git root is also available to the build tool itself and
can, e.g., be used as fallback CAS.
|
|
In the rare cases that we need to shell out to git, let the user
configure what binary to use. Option resolves in the same way as
the just executable, including allowing it to be set via just-mrrc.
Updates all cases of shelling out to git (fetch and commit update).
Update just-mr and just-mrrc docs accordingly.
|
|
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.
|
|
|
|
|
|
Also update just-mr section-1 man page
|
|
Make clear what fields the defined boolean values refer to.
|
|
|
|
|
|
Contains the logic for the checkout of all supported repositories.
|
|
Calls libcurl to fetch the archives from the internet.
|
|
|
