Bazel 1.0+ failures due to virtual source root (/_virtual_imports/) #308
Comments
|
This quick-'n-dirty patch allowed me to build at least the jars. Doesn't look like the most stable change, but I'll just leave it here for reference. --- bazel/protobuf.bzl
+++ bazel/protobuf.bzl
@@ -5,6 +5,9 @@ def _proto_path(proto):
The proto path is not really a file path
It's the path to the proto that was seen when the descriptor file was generated.
"""
+ if is_in_virtual_imports(proto):
+ return _strip_virtual_import(proto.path)
+
path = proto.path
root = proto.root.path
ws = proto.owner.workspace_root
@@ -18,6 +21,11 @@ def _proto_path(proto):
path = path[1:]
return path
+def _strip_virtual_import(path):
+ pos = path.find(_VIRTUAL_IMPORTS)
+ path = path[pos + len(_VIRTUAL_IMPORTS):]
+ return path.split("/", 1)[-1]
+
def _protoc_cc_output_files(proto_file_sources):
cc_hdrs = []
cc_srcs = []
@@ -298,3 +306,21 @@ python_proto_gen_validate = rule(
output_to_genfiles = True,
implementation = _protoc_gen_validate_python_impl,
)
+
+# From https://github.com/grpc/grpc/blob/2e7d6b94eaf6b0e11add27606b4fe3d0b7216154/bazel/protobuf.bzl:
+
+_VIRTUAL_IMPORTS = "/_virtual_imports/"
+
+def is_in_virtual_imports(source_file, virtual_folder = _VIRTUAL_IMPORTS):
+ """Determines if source_file is virtual (is placed in _virtual_imports
+ subdirectory). The output of all proto_library targets which use
+ import_prefix and/or strip_import_prefix arguments is placed under
+ _virtual_imports directory.
+ Args:
+ source_file: A proto file.
+ virtual_folder: The virtual folder name (is set to "_virtual_imports"
+ by default)
+ Returns:
+ True if source_file is located under _virtual_imports, False otherwise.
+ """
+ return not source_file.is_source and virtual_folder in source_file.path |
|
I'm hit by this using the following: WORKSPACE: ##############################################################################
# gRPC-web
##############################################################################
http_archive(
name = "io_bazel_rules_closure",
strip_prefix = "rules_closure-master",
urls = [
"https://github.com/bazelbuild/rules_closure/archive/master.zip",
],
)
load("@io_bazel_rules_closure//closure:repositories.bzl", "rules_closure_dependencies", "rules_closure_toolchains")
rules_closure_dependencies()
rules_closure_toolchains()
http_archive(
name = "com_github_grpc_grpc_web",
strip_prefix = "grpc-web-1.0.7", # 1.0.7
urls = ["https://github.com/grpc/grpc-web/archive/1.0.7.zip"],
)
#@unused
load("@com_github_grpc_grpc_web//bazel:closure_grpc_web_library.bzl", "closure_grpc_web_library")BUILD.bzl ##############################################################################
# JS gRPC-web
##############################################################################
load("@com_github_grpc_grpc_web//bazel:closure_grpc_web_library.bzl", "closure_grpc_web_library")
closure_grpc_web_library(
name = "product_web_lib",
deps = [
":product_proto",
]
) |
|
@gattytto Your example does not include anything from this project (protoc-gen-validate). What makes you post it here? More Bazel projects using Protobuf have issues. In this case maybe check with |
|
@gertvdijk you are right I'm sorry for the offtopic, this seems to be a bazel specific issue |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
For envoyproxy/envoy#9490 envoyproxy/envoy#9489 envoyproxy/envoy#9488 Signed-off-by: Lizan Zhou lizan@tetrate.io
|
I still encounter it when using the v0.4.0 tag which seems to include #327. This is what I have: Note this path: It starts with |
|
@Kernald I still haven't validated a newer release with this this PR yet, but what I can say is that the check including a leading slash works for me/us (check my local patch). I'm wondering what leads up to your situation. Do you have proto files in the root of your project or something? 😕 |
|
@gertvdijk I haven't. The structure I have is a proto target in |
(This is a quick report, I can make a minimal example some time later.)
Has anybody tried to use the combination of:
protoc-gen-validate's pgv Bazel rules?I'm having issues with (at least) the build of the java_proto_gen_validate srcjars.
with sandbox debugging I see protoc invocations that explain this error:
Having a look at the argument
is not helping to make
google/protobuf/timestamp.protoimportable...I believe bazelbuild/bazel#9215 is the cause for this and the Bazel rules require updates, similar to adjustments made in e.g. bazelbuild/rules_swift#298.
The text was updated successfully, but these errors were encountered: