| Age | Commit message (Collapse) | Author |
|---|
|
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".
|
|
... and hence accidentally picking up executables from the
current working directory.
|
|
... which should accumulate values from all base targets
unless the flag type (CFLAGS, CXXFLAGS, or LDFLAGS) is
explicity overwritten by the inheritor.
|
|
|
|
|
|
|
|
... so that if e.g., libfoo depends on libbar via "deps",
the flag "-lbar" should be filtered out from the flag file
generated via pkg-config from file foo.pc. Omitting these
flags is always correct, due to those libraries being part
of the explicit link dependencies already.
|
|
... 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.
|
|
|
|
When a shared library is picked up from the host system via pkg-config
that is located at a non-standard location, binaries linked against
this library by a standard linker either need LD_LIBRARY_PATH set
appropriately, or -rpath set at link time. However, not all custom
installations set -rpath in the link flags in their pkg-config file.
Therefore, in order to get working binaries (and not have to set
custom paths in tests), add a -rpath for every -L option found in
the ldflags provided by pkg-config.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... and coreutils by default. This has the advantage that no
C compiler and no specific toolchain definition is required
to build rule-internal tools. 'expand_exec' is provided via
an implicit target with proper config transition for host,
so it could be overwritten by the rule user. The C code of
the previous implementation is still kept as an example.
|
|
For maximum compatibility, we use the uppercase types from the
typing package instead of the built-in types, therefore compliant
with PEP 484 and PEP 526.
|
|
|
