| Age | Commit message (Collapse) | Author |
|---|
|
... instead of a property of the library itself. An object library is
not a meaningful concept in itself; it only exists, because a consumer
wants to link the library in its entirety. But consumer-specified
properties should be propagated through configuration transitions
and the definition of the library should not care about how it is
consumed; this is also the approach we follow with respect to building
a library position independent. As oposed to position-independent
building, however, the property of being included unconditionally
is not propagated transitively.
|
|
|
|
... 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.
|
|
... by running a shell prolog with the provided shell to set
PATH to the absolut paths of the shell-provided bin dirs.
|
|
|
|
... 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When setting CC, etc, in foreign rules, it is often useful to have it
set as absolute path. This originally was achieved using realpath(1).
This, however, implies that symbolic links are followed as well,
which confuses some compilers if they are not called with correct
argv[0]. Therefore, 4e86f756bddca8db402502be47c0825e1e2aeb0d tries
to replace this by concatenation with $(pwd), which, however, is
only correct for tools brought locally by the toolchain. Hence fix
the test by not evaluating it in the shell at all and rather using
the knowledge about toolchain versus system tools that the rules
have anyway.
|
|
|
|
|
|
|
|
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.
|
|
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 throwing it away after correctly computing it. Fixes the environment
if the shell defaults bring a custom path.
|
|
... as shell environment variable has to be a string, not a list.
|
|
Add a new rule to execute shell comands, honoring the shell tool
chain. Is is done in such a way, that coreutils (in particular,
pwd) can also come from the binary dirs of the shell tool chain.
|
|
... to declare directories inside the toolchain that contain additional
binaries.
|
|
|
|
... 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.
|
