Issues building protos, and using them #388
Comments
When using
|
|
Regarding Regarding |
|
@Yannic, i actually got it to work somehow, i'm still trying to figure out now if i'm using a fork and it's my local state, or if it was fixed in master for my use case. but thank you for your response in any case. regarding |
|
@Yannic then again, if that one dep supports aliases, and transitive dependencies, that would be fine with us (in terms of |
|
@gkdn please, could we merge that PR, pending a better approach? 😁 |
|
@sgammon We have this restriction to one entry to be in sync what I'm not sure what you mean by alias, but transitive dependencies should just work. proto_library(
name = "a_proto",
srcs = ["a.proto"],
)
closure_proto_library(
name = "a_closure_proto",
deps = [":a_proto"],
)
proto_library(
name = "b_proto",
srcs = ["b.proto"],
deps = [":a_proto"],
)
proto_library(
name = "c_proto",
srcs = ["c.proto"],
deps = [":b_proto"],
)
closure_proto_library(
name = "c_closure_proto",
deps = [":c_proto"],
)
closure_js_library(
name = "my_lib",
srcs = [
# Use everything from `a.proto` and `c.proto`, no need to add an explicit dependency on `b.proto`.
# Using stuff from `b.proto` directly (e.g. `goog.require`'ing it) is possible if you suppress the indirect dependency warnings.
],
deps = [":a_closure_proto", ":c_closure_proto"],
)Does this answer your question? |
|
yes, i think that does help. so it's just that we need to get that PR merged, so we can use that new rule with Soy (just clarifying)? |
|
I think so, but that's @gkdn's decision. |
|
@Yannic one more question, if you don't mind. our i would use is there any equivalent to AFAICT, the new rule fixes this by using binary descriptors, rather than needing proto sources. am I right about that? |
|
AFAICT, there is no equivalent to I'm not sure if |
|
@Yannic actually, using i'm using it with soy now, building templates (that reference protos) that render correctly, using the |
|
@Yannic, pardon me, i spoke too soon. it was working perfectly because the underlying proto had no imports in it. with a more complex example, i get the following output (i'll file an issue and list this there as well): The key item there, of course, is |
Hey there
rules_closurefolks,I was wondering if someone could help me out with compilation and use of protos from Soy (in JS and Java). First things first, I'm aware there is not yet support in
rules_closurefor proto use from Java, although I was not able to answer that question fully for JS.SomeModel.proto:WORKSPACE:BUILD:I can't get Soy to recognize the proto types, whether I'm using
closure_js_proto_libraryorclosure_proto_library. The behavior seems rather strange:When using
closure_js_proto_library:closure_js_template_libraryrule, like so:verbose_failureson):When I examine the file
bazel-out/darwin-fastbuild/genfiles/external/schema/.../SomeModel-descriptor-set.proto.bin, it contains a binary representation of the proto. So, it does compile the proto.I can also accurately find a JS representation of the proto, in
bazel-out. It's in Closure format (goog.require/goog.provide), which is how I want it, but I don't see how I can reference that file.It seems to me, that one of
closure_js_template_libraryorclosure_js_proto_libraryis expecting the protos to be in source form (hence the messageNo syntax specified for the proto file)? What am I doing wrong?The text was updated successfully, but these errors were encountered: