Age | Commit message (Collapse) | Author |
|
Shared libraries require their (direct and indirect) dependencies to be built
in a position independent way. This might cause such a dependent library to be
built twice. As, however, shared libraries need not forward their static
dependencies this does not cause staging conflicts. Verify that this is also
the case for distant indirect dependencies.
Co-authored-by: Klaus Aehlig <klaus.aehlig@huawei.com>
|
|
|
|
When a shared library is built that depends on other shared libraries, it
instructs its consumers via the "run-link-args" to link only against this
library and not also against its dependencies.
|
|
When a shared library has static-library dependencies, it is linked against
these static libraries including all their link arguments. Thus, the
"link-deps" as well as the "link-args" provider of the shared library should be
empty.
|
|
|
|
|
|
... as using the built-in "[]" directly is cleaner and equally
readable.
|
|
|
|
|
|
|
|
... through all our various rules and forms of libraries.
|
|
... provided the configuration variable "LINT" is set.
|
|
... provided the configuration variable "LINT" is set.
|
|
... by fixing a copy&paste error in the TARGETS file of the example.
|
|
|
|
|
|
... 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.
|
|
|
|
... for certain fields, in particular, the "components".
|
|
... for certain fields, in particular, the "components".
|
|
... however not their runfiles, as those become the runfiles
of the resulting library.
|
|
Components themselves can have public dependencies; those
need to be available (as compile deps) for the combined
library. Verify this by extending the test such that the
public dependency is actually used in the header file.
While there, also increase coverage by assertions.
|
|
... however not their runfiles, as those become the runfiles
of the resulting library.
|
|
|
|
|
|
|
|
... 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.
|