-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Minimize output of --toolchain_resolution_debug #7713
Labels
help wanted
Someone outside the Bazel team could own this
P2
We'll consider working on this in future. (Assignee optional)
team-Configurability
platforms, toolchains, cquery, select(), config transitions
type: feature request
Comments
see also b/126375095 |
This is being left open because it's still an issue, but I don't have any good ideas for better ways to report this output. If anyone does have ideas, I'd welcome comments or PRs. |
bazel-io
pushed a commit
that referenced
this issue
Sep 30, 2020
When multiple toolchain types are resolved, skyframe functions run in parallel and the debug output is often hard to follow. Adding type of toolchain to each message makes it possible to analyse the results better. Also after a execution transition, target changes. Added target label to the message, to be able to tell for which target toolchain was selected. Removing initial messages "Looking for toolchain of type...", "Considering toolchain...". With additional fields displayed they become obsolete. Condensing 'rejection explanation', i.e. which values are mismatched, into a single line. #7713, b/126375095: there is still some duplications in ToolchainResolutionFunction:125, which I didn't remove because some tests depend on it (when specifying extra_toolchains) b/117279695 is fixed with this Closes #12196. PiperOrigin-RevId: 334613787
Yannic
pushed a commit
to Yannic/bazel
that referenced
this issue
Oct 5, 2020
When multiple toolchain types are resolved, skyframe functions run in parallel and the debug output is often hard to follow. Adding type of toolchain to each message makes it possible to analyse the results better. Also after a execution transition, target changes. Added target label to the message, to be able to tell for which target toolchain was selected. Removing initial messages "Looking for toolchain of type...", "Considering toolchain...". With additional fields displayed they become obsolete. Condensing 'rejection explanation', i.e. which values are mismatched, into a single line. bazelbuild#7713, b/126375095: there is still some duplications in ToolchainResolutionFunction:125, which I didn't remove because some tests depend on it (when specifying extra_toolchains) b/117279695 is fixed with this Closes bazelbuild#12196. PiperOrigin-RevId: 334613787
katre
added a commit
to katre/bazel
that referenced
this issue
Mar 11, 2021
…es to debug Work towards bazelbuild#12110. Fixes bazelbuild#7713.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
help wanted
Someone outside the Bazel team could own this
P2
We'll consider working on this in future. (Assignee optional)
team-Configurability
platforms, toolchains, cquery, select(), config transitions
type: feature request
Description of the problem / feature request:
--toolchain_resolution_debug contains useful information for understanding why a toolchain was selected, but it's also very verbose - in an example case involving the Go rules, 1600 lines of output mostly of the form "considering X; constraint doesn't match; rejected X", plus a large number of repeated lines when unspecified actions choose a toolchain ("Selected execution platform //:builder_platform, type @io_bazel_rules_go//go:toolchain -> toolchain @go_sdk//:go_linux_amd64-impl" 800 times)
Feature requests: what underlying problem are you trying to solve with this feature?
It'd be nice if this could be more compacted, and easier to scan. E.g. by collecting up the resolution details first, then producing a compact structured output second -
For matching of toolchains against actions themselves, it seems it'd be better to either omit those lines, or to emit the target as well - 800 lines saying the go toolchain was selected but without context don't quite solve that well.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Add --toolchain_resolution_debug to any build including Go.
The text was updated successfully, but these errors were encountered: