Fix ginkgo run with Golang 1.10 snap archive on Ubuntu 18.04

[joestringer]

Since Golang 1.10, this option should no longer be required:

https://golang.org/doc/go1.10#build

The old advice to add the -i flag for speed, as in go build -i or go
test -i, is no longer necessary: builds run just as fast without -i. For
more details, see go help cache.

Furthermore, it creates issues like the below when running ginkgo
against a snap-installed version of Golang 1.10 on Ubuntu 18.04:

$ ginkgo build
Compiling test...
Failed to compile test:

go test runtime/cgo: open /snap/go/2130/pkg/linux_amd64/runtime/cgo.a: read-only file system

Fixes: #504

[nodo]

Thanks @joestringer !

I am a bit concerned in removing the -i flag, since we are currently supporting Go 1.6. Also, I have tried to reproduce the steps and seem very different from yours. Could this be an issue with Snap?

[joestringer]

Hi @nodo!

I can definitely appreciate that, Golang 1.10 is fairly new.

For a bit more information, the maintainer of the Snap package described part of the issue here (some quotes below):

golang/go#24674 (comment)

For the snap packaging, I do know why runtime/cgo appears stale. It's fairly obscure though: the snap packaging builds runtime/cgo with particular C compiler flags to ensure that the generated .o files can be handled by older compilers. The go tool now keeps track of these, so unless you happen to use exactly the same flags, the go tool considers runtime/cgo to be stale.

Some others on the same thread suggested that people should just move away from -i, which makes sense if you can guarantee Golang 1.10.

Perhaps a better alternative would be to be able to parameterize this option rather than hardcoding it? By default, it could always add -i, then for users on newer Golang already they set some config option somewhere to disable the -i, or alias something like ginkgo=ginkgo --build-opts-i=false?

[ueokande]

Same issues occurs when Go modules introduced in Go1.11 is enabled. I used official Go compiler.
Ginkgo should detect go version and remove -i flag when Go 1.10 or later version is used.

[joestringer]

@ueokande Perhaps then there's a better way that uses something like https://golang.org/pkg/runtime/#Version to detect and inject this at runtime.

/cc @nodo thoughts?

[ymmt2005]

It would be better to use build constraints:
https://golang.org/pkg/go/build/#hdr-Build_Constraints

To have different build args for Go <1.10 and >=1.10, create these two files:

build_args.go:

// +build go1.10

var buildArgs = []string{"test", "-c"}

build_args_old.go:

// +build !go1.10

var buildArgs = []string{"test", "-c", "-i"}

and reference buildArgs like this:

func (t *TestRunner) BuildArgs(path string) []string {
    args := make([]string, len(buildArgs), len(buildArgs)+3)
    copy(args, buildArgs)
    args = append(args, "-o", path, t.Suite.Path)
    ...
}

[joestringer]

Thanks @ymmt2005, I used your approach.

[nodo]

Thanks all, it makes sense to me! I will have a more close look later today.

[joestringer]

@nodo did you get a chance to take a look?

[nodo]

Hey @joestringer - looks good to me I have a few doubts about the testing, but I cannot think about a better solution for now 😄

Thanks a lot for contributing! 💯

[joestringer]

@nodo Thanks! I agree it's not the most elegant, but I couldn't think of something better.

Fortunately I think if the testing changes significantly and this breaks, it should err on the side of "breaking when it shouldn't" rather than "hiding a breakage when it should break".

[ymmt2005]

Thanks!

Just for your information, you can use buildArgs to construct the expected value in testing.