Qnx doc transition - #939
Conversation
| "//command_line_option:extra_toolchains": [ | ||
| "@gcc_toolchain_x86_64//:cc_toolchain", | ||
| "@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_unknown_linux_gnu", | ||
| "//bazel/toolchains:score_communication_libclang_toolchain", | ||
| "@score_qnx_x86_64_ifs_toolchain//:ifs-x86_64-qnx-sdp_8.0.0", | ||
| "@score_qcc_x86_64_toolchain//:x86_64-qnx-sdp_8.0.0", | ||
| ], | ||
| "//command_line_option:platforms": "@score_bazel_platforms//:x86_64-qnx-sdp_8.0.0-posix", |
There was a problem hiding this comment.
This is quite uggly... I understand that there is no better workaround. But we should at least put a warning in the bazelrc that the list there must be kept in sync with this list here.
Having the two lists diverge can lead to interesting problems.
There was a problem hiding this comment.
Good catch — this exact duplication is now gone: the QNX toolchains (@score_qnx_x86_64_ifs_toolchain//:ifs-x86_64-qnx-sdp_8.0.0 and @score_qcc_x86_64_toolchain//:x86_64-qnx-sdp_8.0.0) are declared in MODULE.bazel but were previously only registered via .bazelrc. I added a register_toolchains(...) call for them in MODULE.bazel, so the transition no longer needs to list any toolchains at all — it only sets //command_line_option:platforms. That removes the two-lists-must-stay-in-sync problem entirely rather than just warning about it. Pushed as 46ba34d8; verified bazel build //docs/sphinx:sphinx_doc and bazel build --config=qnx_x86_64 //score/message_passing:qnx_dispatch_test (identical resolved config, cache-hit) both still succeed.
There was a problem hiding this comment.
Follow-up: you're right that having register_toolchains() in MODULE.bazel alongside the same toolchains still listed via --extra_toolchains in .bazelrc's qnx_x86_64/qnx_arm64 configs just moved the duplication rather than removing it. Removed those four now-redundant --extra_toolchains lines from .bazelrc (the ifs/qcc toolchains for both x86_64 and arm64) and extended register_toolchains() to cover all four, so each toolchain is now declared in exactly one place. The ferrocene toolchain entries stay in .bazelrc since they aren't part of this transition/global-registration scope. Verified bazel build //docs/sphinx:sphinx_doc, --config=qnx_x86_64, and --config=qnx_arm64 all still resolve toolchains correctly. Pushed as 5e2fa67f.
46ba34d to
5e2fa67
Compare
|
|
||
| visibility(["//..."]) | ||
|
|
||
| _QNX_PLATFORM = "@score_bazel_platforms//:x86_64-qnx-sdp_8.0.0-posix" |
There was a problem hiding this comment.
Given that we want to employ arm64 runners in CI at some point in time, will this break qnx_arm64 builds?
Should we do an architecture selection for the correct platform?
github-project-automation
Bot
moved this from Backlog
to Done
in COM - Communication FT
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Now that the dependable_element references unit_tests through the test_on_qnx transition, the QNX-only qnx_dispatch_test can be restored to the suite. The transition ensures the suite is analyzed in QNX config, satisfying the target_compatible_with constraint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2 participants
No description provided.