cmd/go: build: add -buildmode=nolink flag

[kevinburke]

My understanding of the "go build" process is it does something like this:

• Figure out all of the dependencies of the package.
• For each dependency, determine whether it has changed since the last time it was built, by checking the .a file or equivalent in $GOPATH/pkg.
• Compile them, in parallel if possible
• Generate the new artifact (a .a file or similar) we checked in net: LookupHost is returning odd values and crashing net tests #2 that is now out of date.
• Link them all into a single binary.

I use vim to edit Go files. The most popular plugin, vim-go, recommends checking compilation by running :GoBuild. I do this frequently to ensure I have syntax correct, imports correct, a working Go program.

:GoBuild changes directory to the directory containing the file you are editing, then runs

go build -tags '' . errors

It builds the "errors" package because vim-go desperately does not want to build any final artifacts, and attempting to build multiple packages turns off the binary building behavior.

However, I notice that this never takes advantage of build caching. That is, if I run :GoBuild and then run :GoBuild again immediately without making changes, it takes 4 seconds on the package I am compiling. If I run go build . to compile an artifact, it is much faster, about 600ms on the second run.

Is there a way to make "go build" take advantage of whatever intermediate build steps exist - the .a files from above, or their equivalents - even if it does not produce a final binary?

Alternatively, can you work with the vim-go maintainers to recommend a different tool for checking a package (and/or test package) contains valid Go syntax and identifiers?

[kevinburke]

See also fatih/vim-go#2245.

[kevinburke]

Another update, the slowness only reproduces when compiling a main package, otherwise it's fast.

[rsc]

This is taking advantage of build caching.
But the cache does not cache executables, so the link is happening (for package main), and that's what must be taking the time.
I feel like there's another open issue for a 'build without link' flag but I am not sure exactly where it is, so I retitled this one.
That's really what's needed here.

[kevinburke]

Ah, thanks Russ!

[qingyunha]

Hi, Is this possibly be accepted, I am making a patch to implement this.

[zikaeroh]

I'm not sure that this is really relevant anymore thanks to the proliferation of gopls; you don't need to manually compile your code anymore to know if it compiles if gopls is checking that, and can run :GoBuild when you actually want the binary.

[qingyunha]

I'm not sure that this is really relevant anymore thanks to the proliferation of gopls; you don't need to manually compile your code anymore to know if it compiles if gopls is checking that, and can run :GoBuild when you actually want the binary.

Thank you @zikaeroh . I'm cursor how gopls do that，does it invoke go tool compile directly ？

[zikaeroh]

It uses x/tools/go/packages (https://pkg.go.dev/golang.org/x/tools/go/packages), which internally calls the Go toolchain for info (without actually "building" binaries or anything).

[qingyunha]

Seems x/tools/go/packages can't find compile errors.

[cherrymui]

I propose we allow -buildmode=archive for main packages.

• For non-main packages (the default) -buildmode=archive already means "to compile the package".
• For non-main packages it generates the .a and then throw it away (the default) or optionally keep it (with the -o flag).

We can just extend that to main packages as well, to mean "compile but not link", and optionally generate the .a file.

As a compiler/linker developer, from time to time I want the main.a file. Currently I have to do go build -x -work and dig it out from the work directory. It would be nice if I can just do go build -buildmode=archive -o main.a.