| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
dependencies
|
|
|
|
dependencies
|
|
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.
|
|
... provided the configuration variable "LINT" is set.
|
|
|
|
While there, also properly transition "srcs" and "private-hdrs"
to the host version.
|
|
|
|
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".
|
|
... however not their runfiles, as those become the runfiles
of the resulting library.
|
|
|
|
... instead of hard-coding ["cqs"].
|
|
|
|
... 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.
|
|
... i.e., dependencies that are to be included into the library
itself. In this way, a large library (convenient for a user to have
single library to care about) can be defined as a collection of
smaller libraries.
Technically, components are like public dependencies on libraries
transitioned to object libraries with the following differences
- the header files (i.e., runfiles) of the components become header
files of the resulting libary, and
- the objects (i.e., artifacts) of the components become objects
of the library rather than link dependencies.
To achive the transfer of the object to the requesting library,
an object library can be instructed to drop the objects from the
link arguments; in order to continue to support tranditional object
libraries in the style of, e.g., cmake, this is done by a different
configuration variable that is transitioned as well. In particular,
the object-library test case (using a configure target) can be
left unchanged.
|
|
... 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.
|
|
|
|
|
|
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 defaulting to "". In this way, an empty default target can
be used as toolchain defaults for systems with default names.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
... 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.
|
|
... which should accumulate values from all base targets
unless the flag type (CFLAGS, CXXFLAGS, or LDFLAGS) is
explicity overwritten by the inheritor.
|
|
|
|
|
|
... instead of creating an ENV from it and propagating this.
The idea is to keep PATH entries separate and only join them
with ":" when we need it. In this way, we can accumulate
PATHs from multiple defaults later, and perform a
deduplication ("nub_left") to shorten the final string
length.
|
|
|
|
... instead of creating an ENV from it and propagating this.
The idea is to keep PATH entries separate and only join them
with ":" when we need it. In this way, we can accumulate
PATHs from multiple defaults later, and perform a
deduplication ("nub_left") to shorten the final string
length.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
