Skip to content

Conversation

@keith
Copy link
Member

@keith keith commented Nov 20, 2025

This is required for correctly loading the protobuf rules. It's
possible we could drop the version here to a lower version, as long as
that version supports the versions of bazel we support. I picked this
because it is the current version being used by bazel 8.0.0 (which is
defined in the .bazelversion). Users can override this in their project
anyways if they need an older one

This is required for correctly loading the protobuf rules. It's
possible we could drop the version here to a lower version, as long as
that version supports the versions of bazel we support. I picked this
because it is the current version being used by bazel 8.0.0 (which is
defined in the .bazelversion). Users can override this in their project
anyways if they need an older one
@llvmbot llvmbot added the bazel "Peripheral" support tier build system: utils/bazel label Nov 20, 2025
@rupprecht
Copy link
Collaborator

I picked this because it is the current version being used by bazel 8.0.0

Any reason not to bump it to the latest stable version (8.4.2)?

I have no problem w/ using this version though. We can bump this and the bazel version itself separately.

@keith
Copy link
Member Author

keith commented Nov 20, 2025

should be totally safe, I can submit a PR to do that but i want to land this one first because it will also touch the MODULE.bazel.lock. it would be reasonably safe to gitignore this file if we wanted to, the value it provides being checked in for this repo is probably minimal and it will be a bit annoying as it drifts if folks don't realize they should check in their diffs

@keith keith merged commit 930066f into llvm:main Nov 20, 2025
14 of 23 checks passed
@keith keith deleted the ks/bazel-add-explicit-dep-on-protobuf branch November 20, 2025 19:20
@keith
Copy link
Member Author

keith commented Nov 20, 2025

#168933

@rupprecht
Copy link
Collaborator

should be totally safe, I can submit a PR to do that but i want to land this one first because it will also touch the MODULE.bazel.lock. it would be reasonably safe to gitignore this file if we wanted to, the value it provides being checked in for this repo is probably minimal and it will be a bit annoying as it drifts if folks don't realize they should check in their diffs

Allegedly, the lockfile format is designed to minimize merge conflicts. But if it becomes a regular problem, sure.

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

Labels

bazel "Peripheral" support tier build system: utils/bazel

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants