proto_compiled_sources outputs to the wrong directory

[ewhauser]

Apply the following patch to the root directory:

diff --git a/example/thing/BUILD.bazel b/example/thing/BUILD.bazel
index afd90373..f91f0eb7 100644
--- a/example/thing/BUILD.bazel
+++ b/example/thing/BUILD.bazel
@@ -7,6 +7,7 @@ load("@build_stack_rules_proto//rules/nodejs:proto_nodejs_library.bzl", "proto_n
 load("@build_stack_rules_proto//rules/py:proto_py_library.bzl", "proto_py_library")
 load("@build_stack_rules_proto//rules/scala:proto_scala_library.bzl", "proto_scala_library")
 load("@build_stack_rules_proto//rules:proto_compile.bzl", "proto_compile")
+load("@build_stack_rules_proto//rules:proto_compiled_sources.bzl", "proto_compiled_sources")
 
 proto_library(
     name = "thing_proto",
@@ -59,10 +60,10 @@ proto_compile(
     proto = "thing_proto",
 )
 
-proto_compile(
+proto_compiled_sources(
     name = "thing_go_compile",
     output_mappings = ["thing.pb.go=github.com/stackb/rules_proto/example/thing/thing.pb.go"],
-    outputs = ["thing.pb.go"],
+    srcs = ["thing.pb.go"],
     plugins = ["@build_stack_rules_proto//plugin/golang/protobuf:protoc-gen-go"],
     proto = "thing_proto",
 )

And then run the update command per the docs:

$ bazel run //example/thing:thing_go_compile.update
INFO: Analyzed target //example/thing:thing_go_compile.update (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //example/thing:thing_go_compile.update up-to-date:
  bazel-bin/example/thing/thing_go_compile.update.update.json
INFO: Elapsed time: 0.858s, Critical Path: 0.02s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
Target //example/thing:thing_go_compile: output files copied to source tree:
  example/thing/example/thing/thing.pb.go

You'll note that the example/thing directory is duplicated in the path. The expected output is that the file would be at example/thing/thing.pb.go.

[ewhauser]

I found another repository (https://github.com/api-definitions/keyval) using these rules and tried their setup. I confirmed that the above behavior does not occur in 7c95feba87ae269d09690fcebb18c77d8b8bcf6a.

I bisected this and tracked it down to 12b7ab45a92958bf33f90a44a10b1a3096fd1c6d as the bad commit.

[sacsar]

I can confirm that reverting 12b7ab45a92958bf33f90a44a10b1a3096fd1c6d partially fixes the issue. The generated go code ends up alongside the originating protobuf, in other words, go_package is not respected.

[sacsar]

Okay, the go_package thing appears to be user error on my part. I haven't figured out my mistake, but I have the same problem using 7c95feba87ae269d09690fcebb18c77d8b8bcf6a, which is known good.

[paiyar]

@pcj Could you please advise if #248 can be reverted?

[pcj]

@paiyar thanks for the notification. Let me take a closer look.

[pcj]

@paiyar agree let's revert that for now. I'll prepare a similar PR that you have on your branch.

[pcj]

Reverted in #315