Allow configuring meson, make and pkgconfig versions via bzlmod exten…

[jsharpe]

…sion

[jsharpe]

@jheaff1 any ideas how I could avoid this hardcoded version number?
I want the end user to not have to do use_repo(tools, "meson_src") if they're using this macro which they currently have to; maybe we should make the toolchain variants have to be declared via a module extension and then generate this toolchain into the toolchain_hub e.g.

tools.meson(version = "1.1.1")
tools.meson(version = "1.1.1", requirements = ["@pypi__numpy"])

?

[novas0x2a]

I'm far from an expert on bzlmod (just started trying to port our stuff) but my observed-so-far impression of best practice here is that use_all_repos is the best you can do: #1420

(If you reuse the same repo name for multiple different versions, my observation is that it causes bazel to delete/recreate the repo; this isn't necessarily a problem for development on HEAD, but if you maintain multiple support branches, it avoids the need for bazel to do extra work when you switch between them if the repo name contains the version).

[jsharpe]

@jheaff1 @UebelAndre One part of this I'm yet to design is what the module extension should look like for selecting between preinstalled tools and prebuilt / built from source tools. Any ideas?

The extension API currently looks like this:

tools.cmake(version = "3.29.1")
tools.ninja(version = "1.12.0")

we could do something like:

tools.cmake(version = "3.29.1", allow_build_from_source = False)
tools.ninja(version = "1.11.1", use_prebuilt_binaries = False)
tools.pkgconfig(preinstalled_version = True)

but very much open to ideas on this.

[jwhpryor]

Out of curiosity, did this PR die? I was hoping to use a new version of Cmake but it looks like this PR was abandoned.

[jsharpe]

Out of curiosity, did this PR die? I was hoping to use a new version of Cmake but it looks like this PR was abandoned.

Not dead, its still on my todo list but haven't had the time to work through all the failures in CI!

[jwhpryor]

Ah wow, truthfully I was not expecting this thread to get revived, I really appreciate you taking a look! I would love to understand how to use your work when it lands. No pressure, but thanks for your effort, and I look forward to it landing!

[jsharpe]

Need a strategy to handle these targets - maybe these tests should be generated in the toolchain hub now?

[Copilot]

Pull Request Overview

This PR refactors the toolchain registration code to allow configuring versions for meson, make, and pkgconfig via the bzlmod extension. Key changes include:

• Removal of the register_toolchains parameter from prebuilt toolchain functions and corresponding documentation updates.
• Consolidation and renaming of built toolchain functions (e.g. cmake_toolchain, make_toolchain, meson_toolchain, pkgconfig_toolchain) for a clearer separation from preinstalled toolchains.
• Updates to dependencies and module registration in repositories and extension files for version configuration support.

Reviewed Changes

Copilot reviewed 12 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
toolchains/private/BUILD.bazel	Removed built toolchain targets for make, cmake, ninja, meson, pkgconfig
toolchains/prebuilt_toolchains.py	Updated function signatures to remove register_toolchains parameter and renamed helper functions
toolchains/built_toolchains.bzl	Refactored built toolchain functions and updated toolchain registration logic
toolchains/BUILD.bazel	Removed legacy toolchain registrations
test/*	Updated workspace and build files to align with new version defaults
foreign_cc/*	Updated dependency defaults and registration, added new hub repo rule, and adjusted meson references
examples/MODULE.bazel and MODULE.bazel	Updated version numbers and repository usage

Comments suppressed due to low confidence (2)

toolchains/prebuilt_toolchains.py:202

• The function signature for prebuilt_toolchains was updated to remove the register_toolchains parameter. Please update the corresponding docstring/comments to reflect this change.

def prebuilt_toolchains(cmake_version, ninja_version):

foreign_cc/extensions.bzl:40

• [nitpick] Consider adding an inline comment explaining the distinction between the prebuilt (e.g. cmake_toolchains) and built (e.g. cmake_toolchains_src) toolchain registration functions to improve code clarity.

    for mod in module_ctx.modules:

[Copilot]

[nitpick] Ensure that the generated BUILD file handles any special characters in toolchain names, targets, or types correctly to avoid malformed BUILD definitions.

[novas0x2a]

Came over here from #1418 (comment); I'm definitely not an expert on bzlmod, but in the (internal) repo I'm currently converting to bzlmod, this MR appears to work (and is slightly easier if you combine it with #1420)

[novas0x2a]

I'm actually wondering if some of these should be marked as dev_dependencies instead; If I were building my own cmake, for example, i definitely wouldn't want the prebuilt toolchain to be registered at all. To give you an idea of what we do today in our workspace file (pre-migration to bzlmod, since bzlmod can't match this yet...)

rules_foreign_cc_dependencies(
    cmake_version = "3.31.7",
    make_version = "4.4.1",
    ninja_version = NINJA_VERSION,
    register_built_pkgconfig_toolchain = False,
    register_preinstalled_tools = False,
)

register_toolchains(
    "//thirdparty:pkgconfig_noop_toolchain",
    "//thirdparty:autoconf_noop_toolchain",
    "//thirdparty:automake_noop_toolchain",
    "//thirdparty:m4_noop_toolchain",
)

To avoid host divergence, we disable every host tool we can and replace them with noop versions (the automake one sets ACLOCAL=false AUTOMAKE=false, for example).

The infrastructural framework toolchains make sense to register unconditionally, I think, but it seems like anything that is affected by configuration at all should only be registered from the root module. (I also should reiterate that I don't really have any idea what "good" looks like for bzlmod, and you shouldn't necessarily take anything I say about it as informed :))