Support translate_c from source

[cerisier]

Starting zig 0.16, zig translate-c is now backed by translate-c project which uses arocc as the c compiler.

It is already advertised that one can depend on the translate-c repository directly to benefit from more translation options.

Since translate-c will soon become a mandatory build-step, we should already express a dependency on translate-c and arocc , and orchestrate the translation from those binaries built from source (or at least offer the option).

This would allow users to benefit from said additional options and overall increased flexibility rather than waiting for newer releases of zig to benefit from translate-c improvements.

For this, I'm not entirely sure of the full API just yet for rules_zig but I was thinking that we could have:

1. A build setting to use a translate-c binary built from source
2. A configuration knob at the toolchain level to allow users to control the source of the translate-c repository OR provide translate-c targets directly.

I already have something in place at ZML for this which takes translate-c target in the zig.toolchain but would love to discuss ideas on that.

We can also be incremental on that and start with a build setting to control legacy vs override behavior and only ask for translate-c label for now + build on top of that for more complete customization.

WDYT ?

[aherrmann]

Nice, I'm all in favor of exposing this feature.

A configuration knob at the toolchain level to allow users to control the source of the translate-c repository OR provide translate-c targets directly.

It sounds like a dedicated toolchain could make sense, the configuration knob for which version would then be a bzlmod extension similar to the current zig toolchain version selection. Does that make sense?

[cerisier]

Do you have an example API in mind ?
For now I have:

zig.toolchain(
    translate_c = "@translate-c",
    zig_version = "0.16.0",
)

And I provide my own //3rd_party/ziglang/translate-c label.

Additionally, I had to define a custom build_setting inside rules_zig to break the cycle because translate-c cannot be built with translate-c dep in the graph.

To break the cycle, I have a select in the zig_toolchain() invocation to pass the label to a mandatory=False translate-c attribute of the zig_toolchain.

[aherrmann]

What I was thinking was, is it necessary for the zig toolchain itself to carry translate-c? The bootstrap issue you encountered (cycle-breaking) suggests that it may be better not to tie them together at the toolchain level.
Instead, there would be a standalone translate-c toolchain, the relevant Zig rules (binary, library, ...) can have an optional dependency on that toolchain (similar to the cc toolchain dep).
Users can provide their choice of a translate-c toolchain by simply declaring and registering a translate-c toolchain instance.
There's a build setting that configures whether to use a translate-c toolchain in the Zig rules.

So, overall, zig.toolchain(zig_version = "0.16.0") remains unchanged, not tangled with translate-c. That also makes the translate-c bootstrap easy.
There's a build setting, something like @rules_zig//zig/settings:translate-c.
For a start users define something like the following and register the toolchain in MODULE.bazel.

load("@rules_zig//translate-c:toolchain.bzl", "translate_c_toolchain")
translate_c_toolchain(
    name = "translate-c",
    translate_c = "//3rd_party/ziglang/translate-c",
)
toolchain(
    name = "translate-c_toolchain",
    toolchain = ":translate-c-toolchain_impl",
    toolchain_type = "@rules_zig//translate-c:toolchain_type",
)

That makes the API changes relatively small. All the existing toolchain and rule APIs pretty much stay the same. We just add the build setting and the translate-c toolchains. We can even defer any bzlmod extensions until later. Does that make sense?

[cerisier]

Makes sense, let me twiddle with the idea !