Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change of toolchain registering API to simplify multiple execution platforms existing for toolchains. #204

Open
BrandonThomasJonesARM opened this issue Dec 3, 2024 · 0 comments

Comments

@BrandonThomasJonesARM
Copy link
Contributor

Following on from the PR that has been merged (#196)

We now have a toolchain registeration API that looks like the following:

bazel_dep(
    name = "hermetic_cc_toolchain",
    version = "",
)

toolchains = use_extension("@hermetic_cc_toolchain//toolchain:ext.bzl", "toolchains")
use_repo(toolchains, "zig_sdk", "zig_sdk-linux-amd64", "zig_sdk-linux-arm64", "zig_sdk-macos-amd64", "zig_sdk-macos-arm64", "zig_sdk-windows-amd64")

_COMMON_EXEC_PLATFORMS = [
    ("linux", "amd64"),
    ("linux", "arm64"),
    ("windows", "amd64"),
    ("macos", "arm64"),
    ("macos", "amd64"),
]

[register_toolchains(
    # if no `--platform` is specified, these toolchains will be used for
    # (linux,darwin,windows)x(amd64,arm64)
    "@zig_sdk-{}-{}//toolchain:linux_amd64_gnu.2.28".format(os, arch),
    "@zig_sdk-{}-{}//toolchain:linux_arm64_gnu.2.28".format(os, arch),
    "@zig_sdk-{}-{}//toolchain:windows_amd64".format(os, arch),
    "@zig_sdk-{}-{}//toolchain:windows_arm64".format(os, arch),
    # "@zig_sdk-{}-{}//toolchain:darwin_amd64".format(os, arch),
    # "@zig_sdk-{}-{}//toolchain:darwin_arm64".format(os, arch),

    # amd64 toolchains for libc-aware platforms:
    "@zig_sdk-{}-{}//libc_aware/toolchain:linux_amd64_gnu.2.28".format(os, arch),
    "@zig_sdk-{}-{}//libc_aware/toolchain:linux_amd64_gnu.2.31".format(os, arch),
    "@zig_sdk-{}-{}//libc_aware/toolchain:linux_amd64_musl".format(os, arch),
    # arm64 toolchains for libc-aware platforms:
    "@zig_sdk-{}-{}//libc_aware/toolchain:linux_arm64_gnu.2.28".format(os, arch),
    "@zig_sdk-{}-{}//libc_aware/toolchain:linux_arm64_musl".format(os, arch),
    # wasm/wasi toolchains
    "@zig_sdk-{}-{}//toolchain:wasip1_wasm".format(os, arch),

    # These toolchains are only registered locally.
    dev_dependency = True,
) for os, arch in _COMMON_EXEC_PLATFORMS]

Technically a user of these toolchains shouldn't need to be informed of the exec platforms available but should get them for "free". I think a better longterm API would be to have something along the lines of:

bazel_dep(
    name = "hermetic_cc_toolchain",
    version = "some-future-version",
)

toolchains = use_extension("@hermetic_cc_toolchain//toolchain:ext.bzl", "toolchains")
use_repo(toolchains, "zig_toolchains")

register_toolchains("@zig_toolchains/...")
#or 
register_toolchains(
    "@zig_toolchains//amd64-windows/...",  # This registers the `amd64-windows` target for all executor platforms known to `hermetic_cc_toolchain`
    "@zig_toolchains//arm64-windows/...",
    "@zig_toolchains//amd64-linux/...",
    "@zig_toolchains//arm64-linux/...",
    "@zig_toolchains//amd64-macos/...",
    "@zig_toolchains//arm64-macos/...",
)

Then, in future zig versions, if more platforms are supported, it does not require the user to list the extra execution platforms.

Since we know the names of each individual toolchain within a execution platforms toolchain repository as they're generated from def target_structs(): it should be possible to create the alias symlink tree needed to create this.

e.g.

#@zig_toolchains/amd64-linux/BUILD.bazel
#                     ^ this is the target platform

alias(
  name = "linux_amd64_gnu.2.28",
#               ^ This is the exec platform
  actual = "@zig_sdk-linux-amd64//toolchain:linux_amd64_gnu.2.28",
)
alias(
  name = "linux_arm64_gnu.2.28",
#               ^ This is the exec platform
  actual = "@zig_sdk-linux-arm64//toolchain:linux_amd64_gnu.2.28",
)

I am happy to implement this and submit another PR, but want to make sure you're happy with the design proposal first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant