| Age | Commit message (Collapse) | Author |
|---|
|
The ToJson method of RemoteAddress was wrongly creating a list
instead of a simple string, thus a wrongly formatted backend
description was being used to shard the target cache. This however
does not affect the correctness of the build.
Changelog also updated accordingly.
|
|
... and improve log messages in case of failure.
|
|
|
|
|
|
The install target, like any other target, has to have artifacts
and runfiles being proper stages, i.e., in such a way that the
keys can be interpreted as names in the file system without causing
conflicts. This property used to be unchecked, thus allowing users
to define mal-formed targets that, when used as inputs to actions,
would result in unspecified layout of the action directory. Fix
this by adding an appropriate check enforcing well-formedness of
the resulting stage.
|
|
... clarifying the effect of the target-cache-key change. In
particular, explain that, as the cache-key format has changed
in a non-overlapping way, no care has to be taken on update, but
old target-cache entries will not be used by the newer version
of the tool.
While there, fix some typos and properly break lines.
|
|
... ensuring that just-mr passes on the specified environment
variables (and only those) to the tree-generating action.
|
|
The cache key for an export target should contain as target name
that of the export target (and its effective configuration) rather
than the exported target. As we computed the repository part of
the cache key for the target included in the key, this was still a
correct cache key except in the case an explicit file reference was
exported (as here, the information that the file was to be taken
rather than the target of the same name got lost). We still fix
this issue by making the implementation match our design (rather
than by including the file-reference bit in the cache key), as the
original design gives the cleaner protocol for target-level caching
as a service.
|
|
...of the internal cache used for keeping track of running operations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... to pass along toolchain settings for current and future
toolchain definitions. Configuration variable
COMPILER_FAMILY is replaced by TOOLCHAIN_CONFIG["FAMILY"].
|
|
|
|
|
|
If install-cas finds a file in the target location, unlink it before
writing (in the same way as install does already). In this way, we
avoid changing other file locations in the presence of hard links.
|
|
|
|
The bytestream server implementation (deployed by just execute) now
stores the temporary files under
$local_build_root/protocol-depenedent/generation-0
so that they can be garbage collected if "just exectue" is terminated
before they are cleaned up.
|
|
|
|
In this way, the user can specify which execution endpoint
to use depending on the execution properties.
|
|
... so that any left-over directories, in case of abnormal termination
are cleaned up eventually.
|
|
|
|
|
|
|
|
|
|
As local execution is tightly coupled to storage, also specify the
layout in the storage configuration. In this way, we have a central
place specifying the layout of just's cache directory and avoid
accidentally getting into conflicting situations. While there, also
move the execution root under the generation regime, to ensure that
left-over execution directories (e.g., after a forceful termination
of the program) eventually get cleaned up by garbage collection.
|
|
Add an option --plain pretending that the remote repository
configuration is the canonical single-repository one. In this way,
repositories not having a multi-repository configuration (e.g.,
code built with a foreign build system) can be imported in the same
way to a template, thus providing a more uniform interface. This
can also be useful, if a repository is to be imported completely
without its transitive dependencis.
|
|
|
|
|
|
|
|
|
|
... asking just to transfer everyting installed to the local CAS first.
|
|
... both with respect to just options and the man page specifications.
Option -L of just-mr was reassigned as a short name for
--local-launcher, matching its use in just. Its place is now
correctly held by the full name option --checkout-locations, as
per the section-1 man page.
|
|
|
|
... instead of only honoring the latest argument. In this way,
standard overlays coming from the launcher configuration can be
amended in individual invocations.
|
|
|
|
|
|
|
|
... 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.
|
|
|
|
|
|
|
|
|
|
While the built-in "configure" rule is forwarding the result of
the configured target, its own effective configuration is not that
of the configured target. The effective configuration is defined
to be that part of the incoming configuration that can potentially
influence the result of that target; in particular, this includes
variables read in defining the configuration transition.
|
|
... and thus allowing the "business logic" in the configuration
target (e.g., setting defaults and derived options) to be shared
by many targets.
|
|
|
