Open sfc-gh-ptabor opened 1 month ago
You can currently work around this issue by adding this to your MODULE.bazel
:
go_deps.gazelle_override(
build_file_generation = "on",
path = "github.com/cncf/xds/go",
)
But I agree: removing go/BUILD
would be preferable, because that would make it work out of the box.
cc @keith @mmorel-35 - should #96 be reverted, or should the /go/BUILD file be removed or fixed?
I’d say, don’t revert it. Just remove go/BUILD.
Oh wait. That does require us to change some of the //go:go. references in MODULE.bazel to //:go/go..
@EdSchouten I'd like to apply your workaround, but I'm using WORKSPACE instead of Bzlmod. Is there an equivalent way to alter a dep?
We are using gazelle to generate bazel bindings to the golang code. The version
v0.0.0-20240905190251-b4127c9b8d78
fails with:The version
github.com/cncf/xds/go@v0.0.0-20240318125728-8a4994d93e50
works ok. It's regression in the newer versions.My hypothesis about the root reason: @keith added in https://github.com/cncf/xds/pull/96 a /go/BUILD file. The file makes gazelle consider this whole subtree as a proper BAZEL project... so suspends gazelle for generating the proper BUILD files in the sub tree... But they are missing there... i.e. there are no proper BUILD files, e.g. in: https://github.com/cncf/xds/tree/main/go/udpa/annotations.
Can we make it either proper bazel project with gazelle generated BUILD targets... or rollback the BUILD file in the subtree at all ?