| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
While activating DEBUG requires setting it to a non-empty map,
providing information on whether and how debugg fission should be
used, we should still allow any logically false value (rather than
just null) to disable a debug build in order to make it easier for
the user to explicitly disable debugging.
Also adopt and fix the documentation strings.
|
|
|
|
...defining the DWARF format packaging tool to use once debug
fission is supported.
|
|
It expects now the key 'USE_DEBUG_FISSION', which enables debug
fission, but does not add any flags on its own. For this, the
'FISSION_CONFIG' key is expected with certain entries that provide
the compile and/or link flags that configure debug fission.
The flags are added only where needed, i.e., before running or
storing the respective compile or link actions.
|
|
...if no flags are otherwise configured (by toolchain or
rule-specific configuration variables).
|
|
If in debug mode
- DEBUGFLAGS replaces any resulting CFLAGS and CXXFLAGS, and
- ADD_DEBUGFLAGS is appended to the resulting debug compile flags.
|
|
... which is configured using a new defaults field
"include_scanner", a tool (script/binary) that generates
a new include tree without unused headers. Example
implementations are provided.
|
|
|
|
Now that justbuild 1.4 is available, the workaround of defining
"nub_left" in terms of "reverse" and "nub_right" is no longer
necessary.
|
|
|
|
|
|
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"].
|
|
... 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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
... 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Backport of commits a382b308b9011606e7d07376808812d51631d558
and 5ae5134804b6edaaffec593868f133dd840ef7df from the
rules-cc repository.
|
