| Age | Commit message (Collapse) | Author |
|---|
|
|
|
... to a value that is a non-existent directory. Too many tools try
search for rc-files in the user's home directory. To make things
worth, the shell as well as many tools take an unset HOME variable
as instruction to look up the the user's home directory in the system
configuration. While it is good practise to write tests in such
a way that they explcitly do not depend on such machine-specific
defaults, still be on the safe side by explictly setting HOME to a
directory in the action directory we know our rules will no create.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
Co-authored-by: Sascha Roloff <sascha.roloff@huawei.com>
|
|
Often it is desirable to run tests in a variety of configurations:
different toolchain used, different target architecture, different
protocol versions in end-to-end tests, etc. The rule ["test", "matrix"]
allows running tests in those exponentially many combinations in
a single target and thus makes full test coverage maintainable.
|
|
While activating DEBUG requires setting it to a non-empty map,
providing information on whether and how debugg fission should be
used, we should still allow any logically false value (rather than
just null) to disable a debug build in order to make it easier for
the user to explicitly disable debugging.
Also adopt and fix the documentation strings.
|
|
|
|
|
|
The "library" and "binary" rules are modified to generate, if
needed, the appropriate DWARF package from the DWARF objects of
their compilation units and the DWARF package files of their link
dependencies, if any. The resulting artifact is made available to
consumers in the provides map.
|
|
|
|
Allow the expressions running the actions producing the library and
binary artifacts to pass along more information to consumers if
needed by extending their return values to maps. Ensure the changes
do not affect other consumers of the current expressions, such as
the test rules, which do not expect extra information besides the
single action artifact.
|
|
...defining the DWARF format packaging tool to use once debug
fission is supported.
|
|
As the command passed to the linter can produce additional outputs
if debug fission is enabled, pass those artifact paths in a new
variable "extra outs", which the ["lint", "targets"] rule can then
make it available in the meta.json file expected by the linter.
|
|
For this purpose, the DEBUG configuration variable is updated to
expect a map with at least the USE_DEBUG_FISSION flag field. If
set, compilation of source files is expected to produce besides the
regular object file also a DWARF file.
|
|
...to reflect the value change from boolean to map.
Behavior of the proto rules remains the same, as only the truth
value of the variable is currently being taken into account.
|
|
It expects now the key 'USE_DEBUG_FISSION', which enables debug
fission, but does not add any flags on its own. For this, the
'FISSION_CONFIG' key is expected with certain entries that provide
the compile and/or link flags that configure debug fission.
The flags are added only where needed, i.e., before running or
storing the respective compile or link actions.
|
|
...if no flags are otherwise configured (by toolchain or
rule-specific configuration variables).
|
|
If in debug mode
- DEBUGFLAGS replaces any resulting CFLAGS and CXXFLAGS, and
- ADD_DEBUGFLAGS is appended to the resulting debug compile flags.
|
|
|
|
...and unset TOOLCHAIN and TOOLCHAIN_DIR.
|
|
The parsing logic was buggy:
- quotation was not properly taken into account
- multiple keys provided as "@KEY1@${KEY2}@KEY3@" were not correctly parsed
- #cmakedefine KEY1 "@KEY2@" was not correctly parsed: in this case, only @KEY2@ must be expanded, provided variable KEY1 is defined
- only lines containing the magic string were processed
|
|
|
|
|
|
... instead of composing a shell command doing a cd first.
|
|
|
|
Now that justbuild 1.4 is available, the workaround of defining
"nub_left" in terms of "reverse" and "nub_right" is no longer
necessary.
|
|
|
|
... containing the names of artifacts (files or directories) that
are from the target itself of the runfiles of direct dependencies.
This allows tools to check some form of strict dependency structure.
|
|
|
|
|
|
|
|
dependencies
|
|
|
|
... as using the built-in "[]" directly is cleaner and equally
readable.
|
|
... and honor those in ["lint", "targets"].
|
|
|
|
... collecting test results similar to the way "install" rules
are typically used; however in such a way that the provider "lint"
is forwarded.
|
|
|
|
While there, also properly transition "srcs" and "private-hdrs"
to the host version.
|
|
In case many "targets" are given, the field "lint" will contain
all the concatenation of the provider "lint" of the given targets.
There is, however, not need to lint the same file in the same
context twice, so deduplicate the targets first. While this does
not change the amount of lint actions carried out (as equal actions
are handled only once anyway), it keeps the summary clean by not
having dulicate entries.
|
|
|
|
If the configuration variable "LINT" is set, also provide information
on compile actions and header files (with preprocessing as described
command, in particular also providing the correct flags) in correct
dependency context. In this way, lint rules can request the needed
information for performing their checks.
|
|
... instead of hard-coding ["cqs"].
|
|
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.
|
|
... to avoid staging conflicts with the toolchain
|
|
In this action we support a user provided toolchain, hence all the
components of the library need to go into a subdirectory to avoid
staiging conflicts.
|
|
... 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.
|
|
... as we need to copy a file, as not all versions of patch accept the file to patch
as argument.
|
|
|
