Upgrade to Bazel 7.4.1

[rpwoodbu]

This requires disabling Bzlmod and cc toolchain resolution. Both of these should be supported in the future.

[rpwoodbu]

I have another branch behind this one to add support for Bazel's platforms and cc toolchain resolution. To avoid a merge conflict, I'll send that PR once this has (hopefully) merged.

[jpieper]

Hi, thanks for the patch!

My bandwidth is limited this month, and for my purposes, I have about a dozen other repos that I want to keep the bazel version in sync on so it may be a while before I can check this. In the meantime, can you share a branch that has the platform work? I'm not opposed to upstreaming that either, although as with this I have other constraints that may make it take longer to review.

[rpwoodbu]

Thanks for the quick reply. I get it; I'm often in the same boat. No rush.

I linked to the platform branch in my previous comment, but here it is again. It should work with Bazel 5, so we could merge without upgrading Bazel if you prefer. Let me know if you'd like me to send that PR.

I'd also be interested in adding Bzlmod support to this repo. Again, that wouldn't break Bazel 5 as it just wouldn't use those bits. It wouldn't be tested with Travis, though (is that even working?). It could be considered experimental. It'd be nice to have your toolchain in the Bzlmod registry. Again, let me know if you'd like that PR. (If that might not get upstreamed, I probably wouldn't bother to do it just for my own fork.)

[rpwoodbu]

FYI: I have actually invested some effort on Bzlmod support. With Bazel 8 now released, I wanted to get rid of its warning about the use of a WORKSPACE file. But I found that it is a little awkward to maintain support for Bazel 5 in the process, due to Bzlmod's "canonical repo names" and thus how the paths under external must be constructed. Let me know if maintaining Bazel 5 support long-term is important to you. If not, I won't bother. Bazel 6.5+ should work without issue.