Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Depend on nogo with a transition and delete go_tool_library #2374

Closed
jayconrod opened this issue Feb 18, 2020 · 4 comments · Fixed by #2474 or #2922
Closed

Depend on nogo with a transition and delete go_tool_library #2374

jayconrod opened this issue Feb 18, 2020 · 4 comments · Fixed by #2474 or #2922

Comments

@jayconrod
Copy link
Contributor

Instead of having the toolchain depend on nogo, a common target like @io_bazel_rules_go//:go_context_data should depend on it. The dependency should transition to a configuration that doesn't depend on nogo. That would break the cyclic dependency.

With that change, we could deprecate go_tool_library, and we could drop a lot of the custom patching for analyses in org_golang_x_tools.

This would also make it possible to use an alternative nogo binary using a command-line flag.

@achew22
Copy link
Member

achew22 commented Feb 18, 2020

I believe this would also allow specifying custom nogo binaries on a per go_binary target basis as well which would be really nifty!

@jayconrod jayconrod added this to the v0.23 milestone Mar 20, 2020
jayconrod pushed a commit to jayconrod/rules_go that referenced this issue May 5, 2020
The nogo binary to use is now specified using a Starlark flag.
For example:

    bazel build --@io_bazel_rules_go//go/config:nogo=@io_bazel_rules_go//:tools_nogo //:hello

.bazelrc is now the recommended way to set this flag. Setting nogo in
go_register_toolchains will still work, though that function may be
deprecated soon. The flag overrides the go_register_toolchains
argument when both are set.

Updates bazel-contrib#2374
Fixes bazel-contrib#2470
jayconrod pushed a commit to jayconrod/rules_go that referenced this issue May 5, 2020
The nogo binary to use is now specified using a Starlark flag.
For example:

    bazel build --@io_bazel_rules_go//go/config:nogo=@io_bazel_rules_go//:tools_nogo //:hello

.bazelrc is now the recommended way to set this flag. Setting nogo in
go_register_toolchains will still work, though that function may be
deprecated soon. The flag overrides the go_register_toolchains
argument when both are set.

Updates bazel-contrib#2374
Fixes bazel-contrib#2470
jayconrod pushed a commit that referenced this issue May 5, 2020
The nogo binary to use is now specified using a Starlark flag.
For example:

    bazel build --@io_bazel_rules_go//go/config:nogo=@io_bazel_rules_go//:tools_nogo //:hello

.bazelrc is now the recommended way to set this flag. Setting nogo in
go_register_toolchains will still work, though that function may be
deprecated soon. The flag overrides the go_register_toolchains
argument when both are set.

Updates #2374
Fixes #2470
jayconrod pushed a commit to jayconrod/rules_go that referenced this issue May 5, 2020
nogo binaries no longer depend on themselves. Since bazel-contrib#2473, the nogo
rule uses a configuration transition to disable nogo for itself and
its dependencies.

This means there's no longer any need for go_tool_library rules for
analyzers and utility packages in org_golang_x_tools. So with this
change, tools_nogo depends on the regular go_library analyzers. The
documentation is updated not to mention go_tool_library anymore.

Additionally, this change replaces the go_tool_library targets in
org_golang_x_tools with aliases to the go_library targets. So nogo
targets that depends on the old symbols should work.

Fixes bazel-contrib#2374
jayconrod pushed a commit that referenced this issue May 5, 2020
nogo binaries no longer depend on themselves. Since #2473, the nogo
rule uses a configuration transition to disable nogo for itself and
its dependencies.

This means there's no longer any need for go_tool_library rules for
analyzers and utility packages in org_golang_x_tools. So with this
change, tools_nogo depends on the regular go_library analyzers. The
documentation is updated not to mention go_tool_library anymore.

Additionally, this change replaces the go_tool_library targets in
org_golang_x_tools with aliases to the go_library targets. So nogo
targets that depends on the old symbols should work.

Fixes #2374
@jayconrod jayconrod reopened this May 8, 2020
jayconrod pushed a commit that referenced this issue May 8, 2020
This rolls back #2473 and #2474 due to #2479, which is caused by bazelbuild/bazel#11291. There doesn't seem to be a way to work around that, and I don't want to hold the release back any longer.

Reopens #2374
Reopens #2470
@jayconrod jayconrod removed this from the v0.23 milestone May 12, 2020
@bartle-stripe
Copy link
Contributor

ooc are there still plans to address this?

@jayconrod
Copy link
Contributor Author

Unfortunately, this is blocked by bazelbuild/bazel#11291.

@tux21b
Copy link

tux21b commented Apr 25, 2021

The upstream bug that has blocked this issue seems to be resolved now: bazelbuild/bazel#11291 (comment)

robfig pushed a commit to robfig/bazel-gazelle that referenced this issue Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants