-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose --proto_compiler to Starlark rules #8485
Comments
Proto toolchain is something that we will eventually do. Pretty much every user of protobuf shares your concern that recompiling protobuf all the time can slow down the build. We are in the middle of many big migrations that all block this effort (Starlark configuration options, and toolchains and platforms most notably) But I find that in practice the issue is not so bad - especially if you use If this is still not good enough workaround for the meantime, you can get away with some boilerplate. Say that |
Although performance of compiling protoc is one of the reasons I'd like to have a precompiled one, its not the only one. We use bazel in a few repositories with mostly go and proto code, and users now need a c toolchain just to compile protoc. We rely on bazel's autoconfiguration and don't have a hermetic c toolchain by default, this led to issues like protocolbuffers/protobuf#5376 where protoc wouldn't compile if users had installed custom c headers using something like homebrew. Getting to a starlark defined c toolchain and disk/remote cache would take away most concerns, but these are reasonable complex to add. I was hoping we could use a precompiled protoc as intermediate solution. Thank you for the config_setting suggestion, I'll see if we can do that and hope a protoc toolchain appears at some point in the future! |
@robbertvanginkel Is this still an issue? Have you found a workaround? I would also like to use a precompiled version of protoc for the exact reasons you specify. |
I believe that this is still a generic problem, maybe with moving the proto rules out to https://github.com/bazelbuild/rules_proto this will be resolved eventually. As workaround, we apply a small patch on rules_go we do the following:
With |
@robbertvanginkel This is amazing, thank you 🥇 |
Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so. |
@sgowroji Still relevant, although it may be fixed by toolchainifying proto rules instead. |
Hello from 2024 :) This was still relevant for me, discussed in https://bazelbuild.slack.com/archives/CKU1D04RM/p1705423119366659 Here's how you do this today with updated patch and platform settings (and slightly different naming)
|
Description of the problem / feature request:
Expose value of
--proto_compiler
to starlark.Feature requests: what underlying problem are you trying to solve with this feature?
I'm trying to use a different protoc binary other than
@com_google_protobuf//:protoc
through the--proto_compiler
bazel flag. This mostly works, except for in my go rules that depend on a separately defined default I cannot modify inhttps://github.com/bazelbuild/rules_go/blob/f900a9e520e9fdb7b81511f9aa5de2e43da19e2a/proto/compiler.bzl#L174-L178
The rules_go maintainers would be open to reading the
--proto_compiler
setting if it is exposed through Starlark. Is there a way to do this today or an idea of exposing a proto toolchain to starlark rules?What operating system are you running Bazel on?
macOS
What's the output of
bazel info release
?release 0.25.2
Have you found anything relevant by searching the web?
rules_go issue: bazelbuild/rules_go#2018 (comment)
Any other information, logs, or outputs that you want to share?
The text was updated successfully, but these errors were encountered: