Repository navigation
Emit empty repository for unsupported host platforms. - #933
Conversation
3405691582
changed the title
|
@3405691582 please follow the instructions to sign your commits: https://github.com/NHSDigital/software-engineering-quality-framework/blob/main/practices/guides/retrospective-commit-signing.md |
The LLVM toolchain fails to configure on hosts where there is no prebuilt LLVM distribution. That aborts every build on such a host, not just targets that use LLVM. Never fail on an unknown platform: os_from_rctx returns the name unchanged, and the repository rules emit an empty repository for anything other than linux and darwin, as they already do for Windows and for hosts without a matching llvm_versions entry. The host's locally configured toolchain is used instead.
|
@helly25 Commit signed. |
|
Initial comment: sounds useful. But also dangerous because a user might think they are using a configured LLVM/Clang build when they in fact do not. It seems to me that we may need to have this fail but allow a config that restricted the platforms for which we want to be active and then do the bypass you propose for everything else. |
|
Instead of registering no toolchain, could we register one that fails when actually resolved? That would avoid load time failures on unsupported platforms while still providing analysis time feedback if a toolchain is actually missing. |
The LLVM toolchain fails to configure on platforms where there is no prebuilt LLVM distribution. That aborts every build on such a host, not just targets that use LLVM. Add a supported_platforms attribute listing the OSes or OS-arch pairs the toolchain is meant for. On any other platform the repository rules emit an empty repository, as they already do for Windows and for platforms without a matching llvm_versions entry, and the host's locally configured toolchain is used instead. Unset, the attribute keeps the current behaviour of failing on an unknown OS, so nobody silently loses the LLVM toolchain on a platform they did not opt out.
|
@helly25 Fair point about silent exceptional behavior. Added a @fmeum's point; we could do this, but doing this alone doesn't help the cross-platform case, since the toolchain would still fail anyway. If you'd still want this part of the change, I can open a separate pr for it, let me know. |
…941) The `supported_platforms` setting added in #933 needs user-facing guidance because excluding a platform can let Bazel select a different compiler. Add a README example and explain exact OS/architecture matching, `exec_os`/`exec_arch` overrides, default validation, compiler fallback, and registration for Bzlmod and WORKSPACE. `linux` and `darwin` are explicit OS-wide values, not string prefixes. Architecture-specific values must use canonical keys, such as `darwin-aarch64`; prefixes, wildcards, and distribution-specific keys are rejected. Add 10 regression tests calling the production matching function. Cover the README example, OS-wide and exact matches, host architecture normalization, execution-platform overrides, excluded platforms, default validation, and expected failures for invalid entries (even when another entry matches). Validation: - All 55 tests under `//toolchain/...` pass with Bazel 9.3.0 in Bzlmod mode and Bazel 7.7.2 in WORKSPACE mode, including the 10 new tests. - Buildifier, Markdownlint, Prettier, and `git diff --check` pass. No production behavior changes. --------- Signed-off-by: helly25 <6420169+helly25@users.noreply.github.com>
The LLVM toolchain fails to configure on hosts where there is no prebuilt LLVM distribution. That aborts every build on such a host, not just targets that use LLVM.
Never fail on an unknown platform: os_from_rctx returns the name unchanged, and the repository rules emit an empty repository for anything other than linux and darwin, as they already do for Windows and for hosts without a matching llvm_versions entry. The host's locally configured toolchain is used instead.