-
Notifications
You must be signed in to change notification settings - Fork 70
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
Use released protoc binaries #36
Conversation
This creates a stub workspace for com_google_protobuf that aliases protoc, protobuf_java, and protobuf_javalite to use the release binaries instead of building them from source. All the other public targets are aliased to the real com_google_protobuf workspace.
This looks good, but I'll take a deeper look once I get back from vacation (leaving for a week right now :) Alternative I was thinking about was to introduce a protobuf toolchain using https://docs.bazel.build/versions/master/toolchains.html. That would save us from using all those aliases and selects (we would effectively replace them with toolchain resolution). Added benefit would be having the abstraction for protobuf toolchain there, and that would allow us to push it further and use .e.g system installed protoc or compile from scratch on the platform that has a precompiled variant ready. Both approaches are equivalent in power, it's just that each optimizes for smth else. What do you think? |
Part of my goal was that existing rules wouldn't have to change, anything depending on @com_google_protobuf//protoc should just keep working, but faster. For example I tested rules_go, rules_closure, and my own custom codegen rules. It looks like toolchains are more flexible, e.g. someone can add their own build of protoc. But i think everything would have to be updated to use the toolchain instead of the binary. I guess that could be an advantage too. If there is some unforseen incompatibility, having users opt in instead of opt-out could be good. |
Overall, this looks good. I‘ll have a deeper look next month (there are a few things that I need to do first). IMO, we eventually should use a proper toolchain for protoc eventually (I started working on this in #25 a while ago), but I‘m not sure how feasible this is right now while some (all) proto rules are still native rules. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, I finally found the time to take a look :).
The overall approach looks good, but there are some things that need a bit of work until this is ready for merging.
/Re Marcel's comment: I might be missing something, but I think this will integrate nicely with proto_toolchain
in the future (i.e. as outlined in the design-doc and #25).
proto/private/BUILD.release
Outdated
visibility = ["//visibility:public"], | ||
) | ||
|
||
# Redirect everything else to the source |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about making this
redirect_targets = [
"wrappers_proto",
# ...
]
[
alias(
name = target,
actual = "@com_github_protocolbuffers_protobuf//:" + target,
visibility = ["//visibility:public"],
)
for target in redirect_targets
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
proto/private/BUILD.release
Outdated
visibility = ["//visibility:public"], | ||
) | ||
|
||
alias( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be an alias. Otherwise, java_proto_library
will depend on @com_github_protocolbuffers_protobuf//:protobuf_java
instead of the jar from maven.
Also, please add a proto_lang_toolchain
for javalite: protocolbuffers/protobuf#6882
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
proto/repositories.bzl
Outdated
|
||
def rules_proto_dependencies(): | ||
for name in dependencies: | ||
maybe(http_archive, name, **dependencies[name]) | ||
for name in maven_dependencies: | ||
maybe(native.maven_jar, name, **maven_dependencies[name]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
native.maven_jar
is deprecated and, AFAICT, is removed in Bazel 2.0.
The preferred way of declaring Java dependencies seems to be https://github.com/bazelbuild/rules_jvm_external these days, but I don't think we can use that here. Hopefully, the federation will solve this issue for us.
//cc @fweikert who seems to be working on integrating rules_proto
into the federation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to java_import_external
proto/private/dependencies.bzl
Outdated
ctx.actions.run_shell( | ||
inputs = [ctx.file.src], | ||
outputs = [ctx.outputs.executable], | ||
command = "cp $1 $2&&chmod +x $2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not add a dependency on bash (because of Windows), but I can't think of a better way to copy binaries :/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I switched to a genrule with both cmd_shell and cmd_bat. Does that work? I don't have a way to test it on windows though.
@ribrdb are you planning on getting this off the finish line? |
I might be able to get back to this next week. Does anyone have ideas on how to handle the java dependencies? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Mostly looks good.
I'll look for someone who can upload to mirror.bazel.build
. In the meantime, can you already add the urls? Convention is http(s)://foo.bar/baz
-> https://mirror.bazel.build/foo.bar/baz
.
proto/private/BUILD.release
Outdated
"protoc_lib", | ||
"protobuf", | ||
"protobuf_lite", | ||
"protobuf_java_util", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to use the maven version for protobuf_java_util
(haven't checked)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, just missed it.
"build_file": "@rules_proto//proto/private:BUILD.protoc", | ||
"sha256": "3994233e61c287a377a9134e658ca3034924849f0e3a82d12b0e6efa2bed4b46", | ||
"urls": [ | ||
"https://github.com/protocolbuffers/protobuf/releases/download/v3.11.3/protoc-3.11.3-linux-aarch_64.zip", |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
As far as I'm concerned, |
Does this allow me to configure Bazel to use the path/label to the binary as opposed to build it or download it? |
- Add script to generate sha256 sums - Get rid of BUILD.protoc_windows
No. |
That's too bad, but I can live with it for now. Are we close to getting this done? Seems the CI is failing the build due to |
Yeah, rules_proto_dependencies was already missing a docstring. I guess I could add one, but I don't know what it would say. We've been using this branch at my company for the last week with no problems, and our builds are much faster. |
proto/private/BUILD.protoc
Outdated
":windows": ["bin/protoc.exe"], | ||
"//conditions:default": ["bin/protoc"] | ||
}), | ||
executable = "protoc_bin", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be protoc.exe
then?
proto/private/BUILD.protoc
Outdated
constraint_values = [ | ||
"@platforms//os:windows", | ||
], | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please run buildifier on this file (should have trailing newline, CI doesn't check these files, unfortunately).
proto/private/dependencies.bzl
Outdated
"sha256": "cf754718b0aa945b00550ed7962ddc167167bd922b842199eeb6505e6f344852", | ||
"strip_prefix": "protobuf-3.11.3", | ||
"urls": [ | ||
"https://mirror.bazel.build/mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.11.3.tar.gz", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"https://mirror.bazel.build/mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.11.3.tar.gz", | |
"https://mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.11.3.tar.gz", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you asking me to upgrade everything to 3.11.4 instead of 3.11.3? Or just fix the broken urls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, yes, this is only about the broken URL. (If you feel like it, you can upgrade to 3.11.4, but I'm not asking for it as part of this PR).
Sorry for the delay, forgot to actually submit my review. |
Co-Authored-By: Yannic <contact@yannic-bonenberger.com>
Co-Authored-By: Yannic <contact@yannic-bonenberger.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just spotted a typo when going through the code again. Maybe address @eklitzke's minor comments too? (LGTM otherwise)
proto/private/dependencies.bzl
Outdated
attrs = { | ||
"_build": attr.label(default = "@rules_proto//proto/private:BUILD.release"), | ||
"_protobuf_bzl": attr.label(default = "@com_github_protocolbuffers_protobuf//:protobuf.bzl"), | ||
"_protobuf_deps_bzl": attr.label(default = "@com_github_protocolbuffers_protobuf//:protobuf.bzl"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/protobuf.bzl/protobuf_deps.bzl
Seems like @lberki 's approval is required because they are code owners. |
193def1
Co-authored-by: Evan Klitzke <evan@eklitzke.org>
Co-authored-by: Evan Klitzke <evan@eklitzke.org>
Co-authored-by: Evan Klitzke <evan@eklitzke.org>
Avoid compiling protoc during bazel build. Based on change in rules_proto bazelbuild/rules_proto#36 rules_proto_dependencies() declares a @com_google_protobuf//:protoc which points to released protoc binary. The tricks is to load that before scala_repositories() which has conditional load for @com_google_protobuf
* Use released protoc binaries Avoid compiling protoc during bazel build. Based on change in rules_proto bazelbuild/rules_proto#36 rules_proto_dependencies() declares a @com_google_protobuf//:protoc which points to released protoc binary. The tricks is to load that before scala_repositories() which has conditional load for @com_google_protobuf * lint fix * Align rules_proto versions * Update readme * Revert "Update readme" This reverts commit b9a3606.
* Use released protoc binaries Avoid compiling protoc during bazel build. Based on change in rules_proto bazelbuild/rules_proto#36 rules_proto_dependencies() declares a @com_google_protobuf//:protoc which points to released protoc binary. The tricks is to load that before scala_repositories() which has conditional load for @com_google_protobuf * lint fix * Align rules_proto versions * Update readme * Revert "Update readme" This reverts commit b9a3606.
* Use released protoc binaries Avoid compiling protoc during bazel build. Based on change in rules_proto bazelbuild/rules_proto#36 rules_proto_dependencies() declares a @com_google_protobuf//:protoc which points to released protoc binary. The tricks is to load that before scala_repositories() which has conditional load for @com_google_protobuf * lint fix * Align rules_proto versions * Update readme * Revert "Update readme" This reverts commit b9a3606.
Hey @ribrdb thanks for the fix. How do I actually use this ? For context I am using I tried adding the recent version to my
I know it is hard to just look at this and find out the reason. Maybe you can tell me how to best debug what is happening? |
@nikunjy FYI, we use |
Here's my first stab at implementing issue #35
I wasn't sure if this code should go here, in https://github.com/protocolbuffers/protobuf or in a separate repo.
This creates a stub workspace with aliases for everything in @com_google_protobuf that either points to the real thing from the protobuf repo, or a binary if it's available. This is mostly working, however I have a few problems: