| 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.
|
|
|
|
|
|
|
|
The "library" and "binary" rules are modified to generate, if
needed, the appropriate DWARF package from the DWARF objects of
their compilation units and the DWARF package files of their link
dependencies, if any. The resulting artifact is made available to
consumers in the provides map.
|
|
|
|
Allow the expressions running the actions producing the library and
binary artifacts to pass along more information to consumers if
needed by extending their return values to maps. Ensure the changes
do not affect other consumers of the current expressions, such as
the test rules, which do not expect extra information besides the
single action artifact.
|
|
...defining the DWARF format packaging tool to use once debug
fission is supported.
|
|
As the command passed to the linter can produce additional outputs
if debug fission is enabled, pass those artifact paths in a new
variable "extra outs", which the ["lint", "targets"] rule can then
make it available in the meta.json file expected by the linter.
|
|
For this purpose, the DEBUG configuration variable is updated to
expect a map with at least the USE_DEBUG_FISSION flag field. If
set, compilation of source files is expected to produce besides the
regular object file also a DWARF file.
|
|
...to reflect the value change from boolean to map.
Behavior of the proto rules remains the same, as only the truth
value of the variable is currently being taken into account.
|
|
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.
|
|
|
|
|
|
...and unset TOOLCHAIN and TOOLCHAIN_DIR.
|
|
... which should abort if the preprocessor failed.
|
|
Those rules call a foreign build system in a single action. Obviously,
those actions are quite different compared to normal build actions;
at the very least, they require more time and resources and generally
also spawn more than a single process. We already support scaling
up the action time out. Now support also adding additional execution
properties, so that they can be schedulded to dedicated workers
or endpoints.
|
|
|
|
... 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.
|
|
... to match what the rule actually does.
|
|
|
|
The parsing logic was buggy:
- quotation was not properly taken into account
- multiple keys provided as "@KEY1@${KEY2}@KEY3@" were not correctly parsed
- #cmakedefine KEY1 "@KEY2@" was not correctly parsed: in this case, only @KEY2@ must be expanded, provided variable KEY1 is defined
- only lines containing the magic string were processed
|
|
* rules/oss:
config_file: Support PATH from defaults
|
|
|
|
... versions prior to 0.5.11.
|
|
|
|
... instead of composing a shell command doing a cd first.
|
|
Now that justbuild 1.4 is available, the workaround of defining
"nub_left" in terms of "reverse" and "nub_right" is no longer
necessary.
|
|
|
|
Now that justbuild 1.4 is available, the workaround of defining
"nub_left" in terms of "reverse" and "nub_right" is no longer
necessary.
|
|
... by honoring "modified-transitions" when determining the headers
of the direct dependencies.
|
|
|
|
|
|
|
|
|
|
... as otherwise we will use the same string in two ways: literal and as a value
to the expanded, making proper quoting impossible. Moreover, it is not
necessary to expand TOOLCHAIN: pointers into the toolchain can be passed
through the "bin dirs" part of the toolchain.
|
|
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.
|
|
|
|
... as using the built-in "[]" directly is cleaner and equally
readable.
|
|
|
|
... provided the configuration variable "LINT" is set.
|
|
|
