Age | Commit message (Collapse) | Author |
|
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
|
|
... in favor of the "tree" built-in rule.
|
|
... 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.
|
|
|
|
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.
|
|
This commit extends the test case for target-level cached artifacts
synchronization to include all locations of a target-cache entry where known
artifacts can be mentioned. These locations are the 'artifacts', 'runfiles',
and 'provides' map and all are considered now as part of the test.
|
|
|
|
|
|
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.
|
|
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.
|
|
Only if the environment variable DEBUG is set, fall back to sequentially
executing the graph generated by the bootstrap version of just.
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
|
|
|
|
... 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.
|
|
|
|
|
|
... while technically not required, it makes it harder to
run into nasty errors.
|
|
|
|
|
|
artifacts between remote and local CAS
|
|
case they got pruned
|
|
between different CASes
|
|
|
|
... to be able to report the respective graph for later analysis
by other tools.
|
|
|
|
... also when determining default module or target.
|
|
|
|
|
|
... otherwise actual blob size might exceed the maximum
transfer size of the CAS client. Therefore, we always have
to use the bytestream client if the size is unknown.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In particular, also add a target that explicitly all dependencies
besides python3 and the C++ compiler which also serves as a machine
checkable documentation.
|
|
|
|
|
|
|
|
|
|
|
|
... conceptually, it was possible that a previous task
decrements the `num_threads_running_` counter before it is
incremented by the next task. Therefore, we have to unify
the queue and thread status in a single counter
(`total_workload_`) and ensure that woken threads increment
it before decrementing it for popping a queue.
|
|
|
|
Before this patch, the built-in "generic" type allowed for just output
files, listed in the field "outs". Now, the type also supports output
directories, listed in the "out_dirs" field. The output directories
are created before the command is executed.
|