| Age | Commit message (Collapse) | Author |
|---|
|
... 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.
|
|
|
|
|
|
This ensures that one can inspect, e.g., generated protobuf source
files (.pb.cc) or standard library headers while debugging proto
libraries or general C++ libraries and binaries, respectively.
|
|
|
|
|
|
|
|
|
|
For libraries the headers of private dependencies were wrongly
skipped from staging. For binaries, no headers were passed at all
in the provides map. To fix these issues, an additional field is
added in the provides map to ensure we collect, and then properly
stage, all needed headers for both libraries and binaries.
|
|
This is useful when we want to install targets built in debug mode,
but do not want to stage all the additional source and header files
if no debugging is being performed, e.g., in tests.
|
|
... instead of defaulting to "". In this way, an empty default target can
be used as toolchain defaults for systems with default names.
|
|
|
|
... instead of hard-coding /bin/sh.
|
|
|
|
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.
|
|
The existing rule is extended to also stage source files if in
debug mode, in order for a debugger to be able to find all needed
symbols. Conflicting paths are allowed; in case of conflicts, the
file from the closest target in the dependency chain wins.
|
|
|
|
Our pkg config rule postprocesses the output of pkgconfig to add
options -rpath where appropriate. This postprocessing, however,
relies on (standard) tools from the environment, in particular
cat(1). Therefore, the environment (in particular PATH) needs to
be set properly for this auxilliary action.
|
|
The C++ programming language is tightly related to the C programming
language. Consequently, the command line interface for C and C++
are also related and share quite a number of compile flags. Honor
this tight connection by have in our defaults a field allowing to
extend both compile flags, those for C as well as those for C++. In
this way, build defaults can be described in a more readable way.
|
|
... to allow test actions to have a larger time out, while not
changing anything in the build actions (and hence being able to
use cache hits from normal build of the library being tested).
|
|
... to the same value as TEST_TMPDIR. While TEST_TMPDIR is the
conventional name that tests should use for their temporary file,
setting TMPDIR as well has the advantage that more library functions
can be used to create temporary files and directories, as quite a
few of them inspect the variable TMPDIR.
While there, also fix some typos in the documentation strings.
|
|
... instead of inlining the code. In this way, we also have all
the checks that the test runner consists of precisely one artifact.
|
|
|
|
... not that everyone has updated to 1.2 or later we can use
the built-in expressions "reverse" and "set".
|
|
... which should accumulate values from all base targets
unless the flag type (CFLAGS, CXXFLAGS, or LDFLAGS) is
explicity overwritten by the inheritor.
|
|
... instead of assuming it to be installed under /usr/bin as we
also do in other places. In this way, we do not make any additional
assumptions on top of the already existing one on the path of env.
|
|
|
