| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
... to match what the rule actually does.
|
|
Now that justbuild 1.4 is available, the workaround of defining
"nub_left" in terms of "reverse" and "nub_right" is no longer
necessary.
|
|
... 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.
|
|
|
|
When setting CC, etc, in foreign rules, it is often useful to have it
set as absolute path. This originally was achieved using realpath(1).
This, however, implies that symbolic links are followed as well,
which confuses some compilers if they are not called with correct
argv[0]. Therefore, 4e86f756bddca8db402502be47c0825e1e2aeb0d tries
to replace this by concatenation with $(pwd), which, however, is
only correct for tools brought locally by the toolchain. Hence fix
the test by not evaluating it in the shell at all and rather using
the knowledge about toolchain versus system tools that the rules
have anyway.
|
|
... and hence accidentally picking up executables from the
current working directory.
|
|
|
|
|
|
|
|
... and coreutils by default. This has the advantage that no
C compiler and no specific toolchain definition is required
to build rule-internal tools. 'expand_exec' is provided via
an implicit target with proper config transition for host,
so it could be overwritten by the rule user. The C code of
the previous implementation is still kept as an example.
|
|
|
