| Age | Commit message (Collapse) | Author |
|---|
|
* rules/oss:
rules: Do not assume out_dirs exist
|
|
|
|
|
|
|
|
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.
|
|
|
|
... containing the names of artifacts (files or directories) that
are from the target itself of the runfiles of direct dependencies.
This allows tools to check some form of strict dependency structure.
|
|
|
|
|
|
|
|
|
|
|
|
... 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
|
|
|
|
|
