Go package cannot handle .proto files in nested subdirectories that do not contain .go files

[ezzatron]

I'm using a PR here to describe the issue so that we can comment/discuss the reproduction code if necessary.

Continuing on from #114, this is a reproduction of the bug we hit in a multi-language repo that has .proto files. In the repo in question, we're trying to achieve having a single .proto file that's used to generate code for a Go server, and a Kotlin client.

The only way we were able to achieve this was to let an IDE handle the code generation on the Kotlin side, which necessitates having the .proto file in a specific path within the repo. We used a symlink from this path back to the .proto file at the root of the repo so that we only need to make updates in a single .proto file.

We use both the protobuf and go packages to handle the Go side of the generation, but something about this setup breaks the go package. When you run make precommit for example, you will get an error like:

$ make precommit
CGO_ENABLED=0 GOOS="darwin" GOARCH="arm64" GOARM="" go build -tags=debug -buildmode=plugin -v -ldflags "-X main.version=0.0.0+1a1d98f" -o "artifacts/build/debug/darwin/arm64/src.so" "./lib/src"
no Go files in /path/to/make-files/makefiles/test/go-protobuf-build-issue-repro/lib/src
make: *** [artifacts/build/debug/darwin/arm64/src.so] Error 1

What's extra weird is that this only seems to happen when the .proto file is in a nested directory (e.g. lib/src as opposed to just lib). The problem also occurs regardless of whether the .proto file is symlinked or copied.

Prior to merging #114, we also found that running make generate would generate the Go code from the .proto file at the root of the repo, then overwrite that generated code with another version generated from the symlinked version of the .proto file. Since the generated code includes some stuff that's affected by the path, it was also causing diff churn and potentially other problems in the generated Go code.

Not sure what the best way to proceed is here, and I feel out of my depth a bit with the way the go package works. But I think maybe we need:

• A fix so that having .proto files in any depth of directory is fine and doesn't break Go builds.
• A way to tell the Go + protobuf generation logic to include/exclude certain paths?