feat: extend the extension to support more version pins

[novas0x2a]

This makes it possible to pin meson, make, and pkgconfig in the same way it was possible with workspaces. I should say: I don't actually know if this is the correct way to do this, I was just following the existing example and it Seems To Work.

[jsharpe]

Unfortunately its not quite enough as the version name is in the generated repository that the toolchain lives in and so as soon as you switch away from the default versions you will get errors due to unresolved repo names.

[novas0x2a]

Unfortunately its not quite enough as the version name is in the generated repository that the toolchain lives in and so as soon as you switch away from the default versions you will get errors due to unresolved repo names.

Hm, you mean, specifically, like here? (I'd actually expect that I'd have to keep the register_toolchains list in sync, so maybe that's not unexpected?).

I also discovered use_all_repos which provides enough information for bazel mod tidy to update the use_repo list (but unfortunately not the register_toolchains list) but that does make it slightly easier for a user to keep track of what repos they've used that they also need to call register_toolchains on

[novas0x2a]

@jsharpe this is the error you meant, right?

WARNING: /path/MODULE.bazel:26:22: The module extension tools defined in @rules_foreign_cc//foreign_cc:extensions.bzl reported incorrect imports of repositories via use_repo():

Not imported, but reported as direct dependencies by the extension (may cause the build to fail):
    cmake-3.31.8-linux-aarch64, cmake-3.31.8-linux-x86_64, cmake-3.31.8-macos-universal, cmake-3.31.8-windows-i386, cmake-3.31.8-windows-x86_64, ninja_1.13.0_linux, ninja_1.13.0_linux-aarch64, ninja_1.13.0_mac, ninja_1.13.0_mac_aarch64, ninja_1.13.0_win

Fix the use_repo calls by running 'bazel mod tidy'.

If so, I put up a solution over here to help keep the list in sync: #1420 (hopefully I understood what you meant?)

[novas0x2a]

Actually, I just realized that I'm not sure this is working as intended. The if not mod.is_root line is causing it to ignore directives given in other modules, too (like the example one, for instance). Was that behavior intended? (Was it maybe supposed to be if not (mod.is_root and mod.name == "rules_foreign_cc") or something like that?)

[jsharpe]

@jsharpe this is the error you meant, right?

WARNING: /path/MODULE.bazel:26:22: The module extension tools defined in @rules_foreign_cc//foreign_cc:extensions.bzl reported incorrect imports of repositories via use_repo():

Not imported, but reported as direct dependencies by the extension (may cause the build to fail):
    cmake-3.31.8-linux-aarch64, cmake-3.31.8-linux-x86_64, cmake-3.31.8-macos-universal, cmake-3.31.8-windows-i386, cmake-3.31.8-windows-x86_64, ninja_1.13.0_linux, ninja_1.13.0_linux-aarch64, ninja_1.13.0_mac, ninja_1.13.0_mac_aarch64, ninja_1.13.0_win

Fix the use_repo calls by running 'bazel mod tidy'.

If so, I put up a solution over here to help keep the list in sync: #1420 (hopefully I understood what you meant?)

Not quite; the error occurs if you try to actually configure the version. Yes you need to fix the if not mod.is_root line too but when you do that then you can be in the situation where e.g. cmake-3.31.8 repositories are never created, but the rules_foreign_cc MODULE.bazel file trys to register a toolchain from it and so you end up with errors.

PR #1158 is the more complete fix for these issues which moves the toolchains into a single hub which removes the need to know the versions in the module. I need to update the docs on that PR but other than that I think its ready to go so any testing / another pair of eyes on those changes are gratefully received if you have the bandwidth to do so.

[novas0x2a]

Not quite; the error occurs if you try to actually configure the version. Yes you need to fix the if not mod.is_root line too but when you do that then you can be in the situation where e.g. cmake-3.31.8 repositories are never created, but the rules_foreign_cc MODULE.bazel file trys to register a toolchain from it and so you end up with errors.

I actually thought about this a bit more, and my gut says now that the problem is you shouldn't actually register the toolchains in rfcc's MODULE.bazel, except as dev_dependencies- registering a toolchain as a non-dev dependency means it can't be disabled by the root module without patching the dep. (This feels like a wart in the bzlmod api that the root module has no way to prevent the registration of toolchains in deps without patches).

I left a bit of a comment about it on the main MR, too: #1158 (comment)

[novas0x2a]

rules_rust appears to have come to a similar conclusion here though the mechanism is different.