| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removed unused file_system_manager dependency
|
|
|
|
|
|
|
|
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
|
|
... so that for every construct supported in rules there is
an analogous one as a built-in rule to allow ad-hoc constructions
without having to write a rule (even though writing a rule is
recommended for everything occuring more than once):
- the "generic" rule allows an ad-hoc ACTION,
- the "file_gen" rule allows an ad-hoc BLOB,
- the "tree" rule allows an an ad-hoc TREE, and
- the "configure" rule allows an ad-hoc configuration transition.
|
|
The dependencies requested in order to read their "outs" or
"runfiles" also contribute to the effective configuration.
|
|
|
|
|
|
... 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.
|
|
|
|
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.
|
|
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.
|
|
|
|
This commit also introduces an incompatible change, since it modifies the way
how files are stored in the just cache directory. This modification reduces the
number of files per directory and only introduces a maximum number new
directories to avoid possible performance bottlenecks.
|
|
This change is introduced to be prepared for future changes such as garbage
collection. It is an incompatible change compared to earlier just versions
since it modifies the local path to the just cache directory, where among
others the CASes, action cache, target-level cache are located.
|
|
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".
|
|
This recursive scan of the provided results map of a target-cache entry for
known artifacts is required since the serialization format of target results
currently does not produce a single flat artifact list, but keeps the result
entry structure with a nested list of artifacts. Once the serialization format
of target results is changed in a way that a flat list of artifacts is
produced, this recursive scan is not required anymore and can be reverted.
|
|
This enforces the explicit specification, which object type, either file or
tree, should be used to create an artifact digest. This also avoids subtile
errors at locations as in the previous commit, where files as well as trees are
supposed to be handled, but digest creation mistakenly defaults to file object
type.
|
|
The initial assumption before introducing the native remote execution protocol
was that only blobs were transmitted over the wire and put in a blob store.
With the native remote execution protocol, also trees can be transmitted over
the wire and they are put in a different store than blobs. Different hashing
functions are used for blobs and trees and need to be calculated accordingly
for data to be put in the correct store. This distinction of blobs and trees is
now implemented. Additionally, a warning is added that checks equality
between the requested digest and the digest computed by the received
content. This check makes sense to detect, e.g., corrupted messages,
unexpected transmission termination, or remote server failure.
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
|
|
|
|
... if the object does not even exist. In that case, a trace
message is produced and the caller is responsible for
reporting errors.
|
|
|
|
|
|
When a tree is taken from a git root, it is not necessarily known on
the remote site. So, as any missing artifact it has to be uploaded,
recursively uploading the parts to keep the tree invariant. The
function RetrieveToCas was doing the correct recursiv pattern, however
inspecting trees incorrectly using the function ReadTreeInfos; the
latter function, however, was obtaining all the leafs of the tree
as is needed for a compatible action-input description. Add and
use a function that reads the direct contents of a tree.
|
|
... as for remote execution, the map entries are only used
for the `install` subcommand. For local execution, much less
tree objects are read from CAS when using this map. However,
the performance benefit is barely measurable and therefore
we rather remove this map entirely to reduce complexity.
|
|
... to align with the original idea of caching a flat list
of blob objects, without the need to recursively traverse
any trees. Consequently, we cannot create any map entry in
places where we do not have all sub-tree entries at hand
(e.g., LocalAPI, BazelAPI, BazelResponse).
|
|
... which is not using `Directory` messages nor does it
support the `GetTree()` rpc.
|
|
... so that any infra structure problem on the remote execution
is reported by default.
|
|
... to emphasize that this is the extensional action identifier,
not the intensional one.
|
|
|
|
|
|
|
