support 'go list -toolexec=garble'

[mvdan]

This would not be directly useful to many users, but it would be very useful internally. For example, go list -toolexec=garble -export -json -deps can compile and provide the archive files for a set of packages and all of their dependencies.

The advantage over running go build -toolexec=garble directly is two-fold:

1. We have the opportunity to run code after all the packages are compiled but before the linker runs. This will probably help with fixing issues like debugdir flag only works if we make it to linking phase #176.

2. Unlike importcfg files, go list -deps is transitive, so indirect dependencies are included. This will let us fix some build failures that @capnspacehook found in complex projects with indirect dependencies (do we have an issue for this?).

[mvdan]

One disadvantage of replacing

go build -toolexec=garble <args>

with

go list -toolexec=garble <args>
go build -toolexec=garble <args>

is that there's a bit of extra overhead for the second executed call to realise that all the packages are already available in the build cache. But this should be reasonably cheap, even for large programs - in the order of tens or hundreds of milliseconds. Plus, I see no other way to fix the two problems shown in the original post.

[mvdan]

But this should be reasonably cheap

If this turns out to not be the case, I guess we could always switch to calling the linker directly. I would avoid that for now, because it will add a bit of complexity to our tool. The linker isn't particularly easy to use directly.

[capnspacehook]

Created an issue that describes what you mentioned: #180

[capnspacehook]

Can #146 be tackled at the same time as this?

[mvdan]

They are sort of related, since they both involve go list, but they are separate issues/fixes.

[mvdan]

2. Unlike importcfg files, go list -deps is transitive, so indirect dependencies are included. This will let us fix some build failures that @capnspacehook found in complex projects with indirect dependencies (do we have an issue for this?).

I was wrong here; simply doing go list -toolexec=garble -export args... does not magically fix the indirect dependency issues. It has to run the build underneath, so any extra information we need at compile time (like action IDs of indirect deps) is not yet available.

1. We have the opportunity to run code after all the packages are compiled but before the linker runs. This will probably help with fixing issues like debugdir flag only works if we make it to linking phase #176.

This could still be an advantage, but fairly minor. #176 already tracks what matters; a bug.

I'm going to close this issue for now, since it's no longer the obvious thing to do. For more, see #203.

[mvdan]

Also, go list -toolexec=garble does work. The PR linked above uses it. So the premise of this issue was wrong too :)