| Age | Commit message (Collapse) | Author |
|---|
|
|
|
...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.
|
|
|
|
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.
|
|
|
|
... and add a rule allowing the summarizer to specify what it needs.
|
|
... as test meta data. Tests are executed in an unspecified directory,
assuming pass or fail is independent of the location where the test
is run. While this generally is true, test logs often contain the
working directory. So, in order to more easily compare different
execution orders of a potential race condition, it can be desirable
to compare logs "up to the execution directory". This, however,
requires that this directory is recored in the first place. Do so.
For consistency of the output format, also have a (fixed) artifact
pwd in the summary report.
|
|
|
|
|
