You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This can already be implemented with something like this:
def proto_encode(name, src, message, proto, deps=[]):
native.genrule(
name = name,
srcs = [ src ] + deps,
outs = [ name + ".binpb" ],
cmd = "protoc --encode={} --descriptor_set_in={} {} < $(location {}) > $@".format(
message, ":".join(["$(location {})".format(n) for n in deps]), proto, src)
)
However, this is very clunky: it requires a hard-coded dependency on the system proto compiler rather than using the same one by the rest of the Bazel stuff (I can't tell if this is exposed anywhere?), and it also requires the author to explicitly pass in the filename of the proto being encoded as well as the message name. This violates layering as the consumer of the proto library shouldn't need to know about the filenames of the source files inside the proto library. Having some bazel magic to make this convenient would be, well, very convenient.
The text was updated successfully, but these errors were encountered:
comius
added
the
P4
This is either out of scope or we don't have bandwidth to review a PR. (No assignee)
label
Jun 10, 2022
Not sure if there is better way now, but below seems to do the trick in hermetic way. This solves just the issue of not using system protoc, not the other ones:
i.e. the equivalent of
protoc --encode=$MESSAGETYPE
. This is useful when embedding binary protos in applications. Something like:This can already be implemented with something like this:
However, this is very clunky: it requires a hard-coded dependency on the system proto compiler rather than using the same one by the rest of the Bazel stuff (I can't tell if this is exposed anywhere?), and it also requires the author to explicitly pass in the filename of the proto being encoded as well as the message name. This violates layering as the consumer of the proto library shouldn't need to know about the filenames of the source files inside the proto library. Having some bazel magic to make this convenient would be, well, very convenient.
The text was updated successfully, but these errors were encountered: