proposal: cmd/go: add pkgspec support to -toolexec #46774
Comments
|
It has been brought to my attention that There may still be value here, but that actually fulfills the need I have. |
|
To be more clear, that fulfills the need I have, when used in combination with #27628 (comment). |
|
The discussion at #41145 may be relevant. |
|
Chiming in since I authored #41145 and implemented TOOLEXEC_IMPORTPATH. My use case is https://github.com/burrowers/garble, which might be one of the more complex use cases for -toolexec out there. Note that garble modifies the output of
As some of the comments have stated, I think #27628 is what we want to do for caching instead. If this proposal were accepted and a toolexec command isn't used for a sub-tree of the built packages, then I think the build tool could simply use its build cache as usual, as if the toolexec command for those packages hadn't printed anything nor modified the output of
I agree that TOOLEXEC_IMPORTPATH plus the control of whether or not package builds are cached should be enough to do pretty much anything I can think of in a reasonably efficient way. Beware that TOOLEXEC_IMPORTPATH is somewhat ambiguous in 1.16.x; that's fixed in 4fe324d. |
|
FWiW, I don't see how we can change -toolexec to admit the new patterns. That would mean something else entirely in the usual -gcflags syntax. It sounds like having TOOLEXEC_IMPORTPATH plus the new caching logic suffices for the use cases we know for more fine-grained tool selection. And certainly that fine-grained tool selection could be implemented in the tool itself by using TOOLEXEC_IMPORTPATH. Should we close this issue? |
|
This proposal has been added to the active column of the proposals project |
|
Based on the discussion above, this proposal seems like a likely decline. |
|
No change in consensus, so declined. |
Today, our best way of benchmarking the compiler is golang.org/x/tools/cmd/compilebench, which mostly works great, but unfortunately has to encode knowledge about internal compiler and linker flags to actually individually benchmark the compiler and linker. This has some issues when trying to benchmark builds of packages outside the standard library, because of things like the
-importcfgflag, and setting all that up.Although a tool could theoretically work around this by parsing the output of
go build -x, this is complex and fraught with issues. This doesn't even include working around all the caching that thegocommand does, which can be worked around with-a, but it means that there's a lot more that needs to execute with each benchmark iteration that isn't even measured.Instead (at @mdempsky's suggestion), I propose adding a pkgspec pattern to
-toolexec's syntax, similar to how-gcflagsand-ldflagswork. In this way, it will be possible to execute a build while wrapping only a specific part of the build. More specifically, it will wrap all commands related to compiling a specific package with the given command prefix. Furthermore, the-toolexecflag can propagate into thegocommand's caching, to always prevent caching of the specified packages.One downside to this proposal is that it will break existing scripts using
-toolexec. By adding in the pkgspec pattern,-toolexecwill have to, by default, only instrument the target package, just like-gcflagsdoes, andallwill need to be explicitly mentioned to get back the original behavior. I'm not sure this breakage will be particularly impactful, but maybe others feel differently.Lastly, although I'm motivated by improving
compilebench, there's some value to this functionality for debugging purposes. For instance, wrapping specific compiler invocations with the Linuxperf recordcommand instead of having to figure out the compiler invocation, extract it, set up the build configuration by passing-work, etc.The text was updated successfully, but these errors were encountered: