Skip to content

Conversation

EdSchouten
Copy link

Though I understand why the authors of this module don't want to permit module extension tag declarations of llvm.toolchain() in non-root modules, not being able to depend on the extension entirely is fairly restrictive.

In one of my Bazel projects I want to be able to use clang-format as part of some reformatting script. These scripts are not just used by the module itself, but also by some other modules that depend on it. I therefore have the following stanza in MODULE.bazel:

llvm_dev = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm", dev_dependency = True)
llvm_dev.toolchain(
    llvm_version = "17.0.6",
)
llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm")
use_repo(llvm, "llvm_toolchain_llvm")

I can then use label @llvm_toolchain_llvm//:bin/clang-format to get a copy of clang-format. The current logic prevents me from doing this, because the second use_extension() call is rejected outright, even if it doesn't invoke llvm.toolchain().

Though I understand why the authors of this module don't want to permit
module extension tag declarations of llvm.toolchain() in non-root
modules, not being able to depend on the extension entirely is fairly
restrictive.

In one of my Bazel projects I want to be able to use clang-format as
part of some reformatting script. These scripts are not just used by the
module itself, but also by some other modules that depend on it. I
therefore have the following stanza in MODULE.bazel:

    llvm_dev = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm", dev_dependency = True)
    llvm_dev.toolchain(
        llvm_version = "17.0.6",
    )
    llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm")
    use_repo(llvm, "llvm_toolchain_llvm")

I can then use label @llvm_toolchain_llvm//:bin/clang-format to get a
copy of clang-format. The current logic prevents me from doing this,
because the second use_extension() call is rejected outright, even if it
doesn't invoke llvm.toolchain().
Copy link
Member

@fmeum fmeum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am slightly worried about the availability of binary tools changing with LLVM versions.

In your module that uses clang-format, is that reformatting script something you would expect to run when that module isn't the root module? If it's a dev tool, wouldn't it be fine to mark both extension usages as dev deps?

If that's not possible for some reason, I'm open to merging this.

@EdSchouten
Copy link
Author

It’s a reformatting script that I keep in bb-storage that’s also capable of reformatting code in any other bb-* repo.

So I’m not able to mark it dev_dependency=True

@helly25
Copy link
Collaborator

helly25 commented Oct 8, 2025

It’s a reformatting script that I keep in bb-storage that’s also capable of reformatting code in any other bb-* repo.

So I’m not able to mark it dev_dependency=True

I assume you are doing something like the following:

"_clang_format_tool": attr.label(
        doc = "The target of the clang-format executable.",
        default = Label("@llvm_toolchain_llvm//:bin/clang-format"),
        allow_single_file = True,
        executable = True,
        cfg = "exec",
    ),

If you are doing something different, mind sharing?

@fmeum
Copy link
Member

fmeum commented Oct 8, 2025

@EdSchouten What do you think of introducing an @rules_go//go style alias for clang-format? A problem with the current approach I only now realized is that such an extension usage would break if the root module doesn't contain a toolchains tag or uses a different name - it would refer to a non-existent repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants