Rules_go: go_proto_library generated sources as implicit output targets

[blico]

I am curious if it is possible for go_proto_library rules to declare their generated sources as implicit output targets.

This would make it possible to query for go_proto_library's generated sources with bazel query 'kind("generated file", ...)'. Also, you could generate a specific file target with something like bazel build //foo/bar:baz.pb.go.

If this is not possible, do you have any recommended way to query a repo for all of its generated sources?

[jayconrod]

I don't think this is feasible for go_proto_library. I'd rather not expose the output file names. It's an implementation detail that's subject to change, and it varies a lot with the proto compiler being used, so I'd prefer not to freeze that in the API.

About querying all generated files: do you mean all generated files from go_proto_library, or all generated files of any kind? go_proto_library makes its source available in the go_generated_srcs output group, though the names of those sources are not frozen. I'm not sure how to query for all generated files. bazel aquery might be able to do it, but I haven't tried it.

[linzhp]

In our repo, we don't check-in generated code. For IDEs to resolve imports, we have to copy all generated code (from proto, thrift, gomock, etc) to somewhere discoverable by IDEs. So we need to find all generated code depended by a project transitively.

There are 3 options we have right now:

1. Build all transitive dependencies of the project. This is the most expensive, but more exhaustive way. It will not only generate the code, but also compile and link them, although for IDEs to resolve imports, we don't need to compile and link generated code. Also, compilation and linking errors will be mixed with code-gen errors. We often have to make the code buildable before making IDEs work. But people often need helps from IDEs to make the code buildable...
2. Add go_generated_srcs output group to all Bazel targets that generate Go code.
3. Like @blico suggested, make existing code-gen rules respond to bazel query 'kind("generated file", ...)'.

Both 2 and 3 require changes to existing Bazel rules. Option 2 is easier to implement, but it's Go specific. I think this is a general problem for any languages when it comes to IDE integration with Bazel. It's better to have some standard interface across different languages to find all generated code. That's why we were thinking about Option 3. Or is there any other plan to help IDEs resolving generated code (well, besides checking in generated code).

[jayconrod]

For IDE support, #512 is the plan. It's been open for a long time, but nothing is blocking it anymore, and it's the highest priority feature work currently planned for rules_go. I haven't been able to give it much attention over the last couple months: keeping up with Bazel incompatible changes has blown my time budget for rules_go and Gazelle. However, Bazel is entering a stability period for a few releases before Bazel 1.0, and I'm hoping to have more time to work on it after rules_go 0.19.0 is out.

[jayconrod]

Closing old issues. I don't think rules_go can do anything beyond the go_generated_srcs output group.