Why both @com_google_protobuf_cc and @com_google_protobuf?

[dione...@gmail.com]

I tried the Bazel native proto examples here:
https://github.com/cgrushko/proto_library
and I have a couple of questions.

Question 1:

According to the BUILD instructions, one needs to define both @com_google_protobuf_cc and @com_google_protobuf like this:

http_archive(
name = "com_google_protobuf",
urls = ["https://github.com/google/protobuf/archive/b4b0e304be5a68de3d0ee1af9b286f958750f5e4.zip"],
strip_prefix = "protobuf-b4b0e304be5a68de3d0ee1af9b286f958750f5e4",
sha256 = "ff771a662fb6bd4d3cc209bcccedef3e93980a49f71df1e987f6afa3bcdcba3a",
)

# cc_proto_library rules implicitly depend on @com_google_protobuf_cc//:cc_toolchain,
# which is the C++ proto runtime (base classes and common utilities).
http_archive(
name = "com_google_protobuf_cc",
urls = ["https://github.com/google/protobuf/archive/b4b0e304be5a68de3d0ee1af9b286f958750f5e4.zip"],
strip_prefix = "protobuf-b4b0e304be5a68de3d0ee1af9b286f958750f5e4",
sha256 = "ff771a662fb6bd4d3cc209bcccedef3e93980a49f71df1e987f6afa3bcdcba3a",
)

Maybe I'm mistaken, but isn't this making two copies of the protobuf repo? Why couldn't the toolchain dependency simply be @com_google_protobuf//:cc_toolchain?

Question 2:

What if I don't want to use the protobuf from the http_archive but rather a local/vendored one that resides under //third_pary/protobuf? Using new_local_repository in this case is unsatisfactory since people cloning the repo would need to update the path for their system.

Why aren't Bazel proto rules assuming protobuf to be an external repo (e.g. //external:protobuf). That way, both the http_archive and local BUILD approaches would work.

[László Csomor]

Hey, thanks for your email!

We recommend posting Bazel related questions on StackOverflow using the 'bazel' tag. We will be happy to answer it there, so that other users can also benefit. I forwarded your question to: https://stackoverflow.com/questions/44494304/why-both-com-google-protobuf-cc-and-com-google-protobuf

Cheers,

Laszlo

--
László Csomor | Software Engineer | laszlo...@google.com

Google Germany GmbH | Erika-Mann-Str. 33 | 80636 München | Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/a2f0955a-c63c-4002-a837-a45125bad05b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ca...@google.com]

Hi,
Question 1 -
In short, it allows different languages to have code generators in different repos. This comes up with JavaLite, which is developed in a separate branch from Java.
In this particular case, proto_library and cc_proto_library could use the same external repo, agreed.

To be honest, I expected Bazel to deduplicate the two repos. There was some internal discussion about an `alias` WORKSPACE rule that would solve the duplication. I filed https://github.com/bazelbuild/bazel/issues/3219

Question 2-
I'm not sure I understand. Can you elaborate?

> To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.