| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Now that justbuild 1.4 is available, the workaround of defining
"nub_left" in terms of "reverse" and "nub_right" is no longer
necessary.
|
|
|
|
|
|
The existing rules allow a shell test script to explicitly 'keep'
created files in the resulting output directory, to be accessible
to any dependent target, thus allowing a chaining of data across
test scripts. This field however excludes directories, whose
content would need to be added one file at a time to the 'keep'
field.
Add instead also a 'keep-dirs' field to ["shell/test", "script"]
rule which allows the explicit staging of given directory paths the
test is expected to generate.
|
|
... of passed tests (as only for those, the time is meaningful).
Given that we read the timing information anyway, if available, we
can as well report more useful information.
|
|
... and add a rule allowing the summarizer to specify what it needs.
|
|
... as test meta data. Tests are executed in an unspecified directory,
assuming pass or fail is independent of the location where the test
is run. While this generally is true, test logs often contain the
working directory. So, in order to more easily compare different
execution orders of a potential race condition, it can be desirable
to compare logs "up to the execution directory". This, however,
requires that this directory is recored in the first place. Do so.
For consistency of the output format, also have a (fixed) artifact
pwd in the summary report.
|
|
If a test is run several times (as set by RUNS_PER_TEST), a summary of
the individual test runs is computed using a summarizer as configured
in the target layer of the rules. As the inputs for computing that
test summary are all the individual test runs, that action has a
large number of files as input, including a large number of identical
files, e.g., the ones indicating the outcome of an individual run.
Therefore, allow setting additional remote-execution properties
allowing to dispatch that action to a suitable end point.
|
|
|
|
|
|
So far, our rules, where depending on the shell, implicitly use
"normal" defaults, hard-coded in the rules. Support configuring
those in a default target, in the same way we do so for other tools,
like the C compiler. In this, it is also possible to bring your
own shell, built as a (compiled) target.
|
|
|
|
|
|
|
|
... and document at the appropriate places what can be overwritten
by setting those targets.
|
|
... provided it is specified on how to obtain a remote-execution
endpoint for the given architecture; in this case, the test (script
and) dependencies will be cross compiled for and run on that
architecture. The actual building (as well as summarizing multiple
test runs) happens on the default execution end point.
|
|
|
|
|
|
|
|
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
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
|
|
|
|
|
|
|
|
... which are more efficient if the caller wants to perform
the union manually (because disjointness should be enforced
or additional maps should be added to the union, etc.). As a
positive side effect, code reuse is slightly increased by
consistently calling these newly introduced expressions for
obtaining the artifacts/runfiles from all targets of a
target field.
|
|
In particular, document the result for the most important
rules.
|
|
|
|
|
|
... allowing to run simple tests given by a shell script.
|
