Enable users to customize cmake and ninja versions with bzlmod

[mrkkrp]

There seem to be no way to override the default cmake (or ninja) version with a tag, although it looks like that was the original intention behind the bzlmod extension. The problem is

• The root module is explicitly skipped because of the conditional if not mod.is_root:
• The use_repo and register_toolchains invocations in MODULE.bazel of rules_foreign_cc have to mention the default version of cmake because it is part of the repository name that provides the toolchain (why?) and so MODULE.bazel is incompatible in the case of an override by the user.

This PR resolves both these issues.

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jsharpe]

Good catch on this. I think how I would like to see this fixed is in a similar way to #1105 where the toolchains are moved into a hub repo which can be generated with all the user requested toolchain versions in it which should remove the need for the use_repo call to need to bring the repos into scope in the parent module.

Actually I have to say I didn't get as far with #1105 as I'd remembered and had only moved the toolchains so that I can register them via :all rather than listing individually. My intentions were to move it into a generated repo to remove the need for the use_repo calls.

[mrkkrp]

@jsharpe Is there anything I can do to help this progress? What do you think about my replies above?

[jsharpe]

@jsharpe Is there anything I can do to help this progress? What do you think about my replies above?

Apologies the limiting factor here is my time availability to work on this as I only maintain this in my spare time. I think really the approach we should take is to generate a hub repo that references all the other versioned repos in the same way that rules_python does so that we can generically register all the toolchains via a //:all target. I've started to work on this in #1158 but haven't found enough time to completely feed through all the refactoring required for this. If you have bandwidth available to pick up that refactoring of the generated toolchains then that'd be great..

[mrkkrp]

I think really the approach we should take is to generate a hub repo that references all the other versioned repos in the same way that rules_python does so that we can generically register all the toolchains via a //:all target.

But if there is only one version of a given tool that is selected in the end, does it make a difference whether its repo name includes the version or it is generic? In any case, this patch solved our immediate problem and we don't think that we will have much more time to contribute to a more elaborate redesign.