search

neugram / ng

scripting language integrated with Go
https://neugram.io
BSD 2-Clause "Simplified" License
916 stars 43 forks source link

ng/eval/genwrap: do not clobber go pkg.a archives #166

Closed sbinet closed 6 years ago

sbinet commented 6 years ago

this was discussed on golang-dev: https://groups.google.com/forum/#!topic/golang-dev/qfa3mHN4ZPA

the gist of it (as I understand it), is that the cache is invalidated for eval tests because when importing a Go package, we re-install it (before generating a plugin enable wrapper of it).

this prevents the cache to kick in because the resulting foo.a file is too new:

$> cd $GOPATH/src/neugram.io/ng/eval
$> GODEBUG=gocachetest=1 go test .
testcache: neugram.io/ng/eval: test ID 52757575512d30675a726e474b693468536e7935 => bc29bcfdd8daa625a5f7f7c0a362c3bb294eb12ea86700027cfb0524fa75846b
testcache: neugram.io/ng/eval: input list not found: cache entry not found
testcache: neugram.io/ng/eval: test ID 667245757663367077315764746c3249384d702d => 47d0a96e117b4c220e0c732771b67b60ad1eab1c5fa175a7dd02c5d008091b13
testcache: neugram.io/ng/eval: input list not found: cache entry not found
testcache: neugram.io/ng/eval: input file /home/binet/sdk/go-master/pkg/linux_amd64/crypto/md5.a: file used as input is too new
ok      neugram.io/ng/eval  4.937s

(this was obtained, even after d9a7f2e was in)

crawshaw commented 6 years ago

We regenerate the .a file because we load it with the go/types package, and we want to make sure we have an up-to-date .a file. In the Go 1.10 caching world, it would be better if we just called "go build" for the package, and then loaded the .a file from the cache. That way the go command would not regenerate the .a file in the typical case.

Is there a way yet to find the .a file for a package in the cache? I believe Russ had discussed doing that, but I haven't been following since my leave started. I'll dig around later today.

crawshaw commented 6 years ago

Yeah there's no cache-aware version of gcimporter, so in lieu of writing one we will have to keep using go install to generate the necessary .a files.

crawshaw commented 6 years ago

OK, I think I can fix this. It will make some import operations very slow on Go 1.9, but I think the focus should be on Go 1.10 anyway thanks to its better plugin support.