There is no concept of a "build runner" any more; it has been split in two:
configurer and maker.
Users of this feature will likely want to no longer override any logic, and
instead consume the configuration file produced by configurer.
If overriding one or the other of these is desired, the feature will need to be
re-introduced (as --override-maker or --override-configurer).
This is intended to replace the common pattern:
print("invalid foobar: '{s}': {t}", ...)
The idea is to not invent imaginary syntax. If the string contained
single quotes for example, this would be a nonsensical error message.
On the other hand with the new pattern:
print("invalid foobar: {q}: {t}", ...)
It's both easier on the eyes at the print site, and also it will allow
the user to copy paste a properly escaped string, should the quoted text
contain any odd characters, including invisible ones like null bytes.
Not sure what I was thinking. This is silly, translate-c package simply
needs to pass this data (link_libc and target) to the CLI application,
which can then do the appropriate behavior.
Currently, neither configurer nor Maker is aware of the standard zig
package path, and the root path is stored as a bare string rather than
relative to a known base directory. Without changing that, we must
construct a cwd relative path here rather than using knowledge of the
standard package path plus package hash.
Also fixes a bug that would have been prevented by implementing the
accepted proposal https://github.com/ziglang/zig/issues/25315
provides a way for the build system to append -target and -isystem/-I
flags to a Run step.
needed by translate-c package to avoid doing naughty stuff in the
configure phase.
It is generally best practice to avoid calling this function, instead
relying on the user to provide these paths via the standard build system
interface. However, when integrating with other build systems, the user
may have already provided the information to the other build system, and
thus it is desirable to use that same information without requiring the
user to provide it again.
options which are passed to configurer and therefore observable by the
build script are added to the cache hash. A sorted list is hashed since
they are unordered.
Andrew Kelley