Go Build should allow for disabling -i

[jwaldrop]

Apologies in advance, I'm a Go neophyte, so I both may have some terminology wrong here, and there may be an easy way to solve this that I'm unaware of.

If I use the Go: Build command, it runs go build -i ./..., which probably works fine when you want to install all of a package's dependencies and speed up the next build. However, in a cross-compilation context, this tries to install to an unwritable location. The usual thing is to run 'go build -v'.

I would try and remove the -i from go.build.workspace or go.build.package trigger, but the src/goBuild.ts code actually assumes it should always be present. I see no way to remove it other than forking the extension.

Because of this, my Go code has red package squiggles because of the permission denied error. I'd like for this stuff to work as intended, but -i is harshing on my fun! 😄

[jwaldrop]

One workaround I've found is to build go from source in a directory that I have write access to. I'm happy to do that if it's considered a "normal" thing to do, since this seems to be an artifact of me using a pre-built Go binary.

[jwaldrop]

For the record, I ended up building the toolchain from source, which has successfully worked around this issue. I'm fine with closing it or leaving it, really up to the people maintaining the project. Long term I think forcing installation of dependencies feels like it should be up to the developer, though.

[ramya-rao-a]

One workaround I've found is to build go from source in a directory that I have write access to

Do you mean building Go itself or the Go code you are writing?

For the record, I ended up building the toolchain from source

What does "toolchain" refer to here?

[jwaldrop]

I mean building Go itself. By toolchain, I simply mean all of the Golang tools -- 'go', 'godoc', etc.

[ramya-rao-a]

Bear with me, I am not too familiar with Go either, so I have some follow up questions

in a cross-compilation context, this tries to install to an unwritable location

You mean the dependencies are attempted to be written to an unwritable location?
AFAIK the location the dependent packages are installed is under GOPATH/pkgs.
How is this different in the cross-compilation context?

Also what exactly are you doing to get into the cross-compilation context?

[jwaldrop]

Cool, we will learn together. :)

I am cross compiling using GOOS and GOARCH environment variables per: https://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5

This blog post also refers to problem I was encountering -- trying to install the dependencies from a pre-built Go distribution (the pre-packaged installs that are available from golang.org) attempts to write to a directory that doesn't normally exist on a Mac (since they are Linux dependencies) and, even if it did, you as a user do not have permission to write to (/usr/local space).

As this blog post points out, you can work around this by building Go yourself from sources, at which point it uses the local build (presumably in your home directory) to write these binary dependencies. They still aren't useful on a Mac, but it allows caching to speed up the build.

[ramya-rao-a]

That was interesting...

So the suggestion is to use Go from source to avoid getting into the "everything is slow" problem when cross-compiling. If that is the suggested way to go, then I believe no change is required from the VS Code Go extension.

On the other hand, to get simple programs cross compiled, it definitely feels like an overkill to have Go from source.

I wouldnt remove the -i option by default because as you know it helps speed up the building process. We could have a setting called say go.enableCrossCompile. If set to true the build process can skip the -i flag.

Anything else the Go extension to VS Code should be doing differently when cross compiling?

[jwaldrop]

So far nope, it works great once my Go compiler is one I built!

Agreed the default should be -i, it just needs to be something you can turn off.

[mwirges]

+1 on this, it would be nice to turn it off when you know you don't need it. For example, I was trying to build / test a simple package with a system installed golang and I didn't really want to go download and build a separate go installation just to work around this (go build/go test failing).

[cardonator]

It seems weird that this plugin doesn't support system installed Go to speak of, though, because that really is the most common install procedure someone is going to use when they try out Go for the first time.

Because of this issue, even having go installed from a Snap in Linux doesn't work right. There are red squiggles all over from the extension trying to install to unwritable locations (Related example from the go issue tracker golang/go#24674). In this case, the runtime/cgo library isn't even out of date, but since -i believes it is, then the extension gives red squiggles.

Please allow an option to disable this behavior or figure out a more ideal workaround. "Slower" builds might be an acceptable compromise to have the tool working better and the system handling the go libraries instead of the user, manually.

[ramya-rao-a]

@jwaldrop @mwirges @cardonator, I have added a setting (go.installDependenciesWhenBuilding) that you can set to false to stop passing -i to go.build. Can you give it a try and let me know if it fixes your current issue before I release it? All you have to do is:

• Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
• Run code --install-extension Go-latest.vsix
• If the above fails with Error: end of central directory record signature not found, then clone this repo and use the Go-latest.vsix file from the cloned repo
• Reload VS Code

[cardonator]

@ramya-rao-a I did have to clone the repo, however setting that setting to false worked so great! Good job and thanks for the fast turnaround! Good bye stupid red squiggles :)

[ramya-rao-a]

This feature is now out in the latest update to the Go extension (0.6.80)