'go generate' in ./go-fuzz requires installing go-bindata

[thepudds]

There is a decent chance I am just confused here, but as far as I can tell, I suspect if your starting point is a clean environment, then running go generate in the go-fuzz/go-fuzz directory requires first installing some flavor of go-bindata.

If you don't, you get an (unhelpful?) error:

Cannot find go-bindata executable in path"
Maybe you need: go get github.com/elazarl/go-bindata-assetfs/..."

(I suspect the advice emitted on the second line there by elazarl/go-bindata-assetfs is incorrect based on briefly looking at that repo, as well as based on trying that suggested step and then seeing it not help ;-)

elazarl/go-bindata-assetfs is vendored by go-fuzz, but I suspect it alone is not complete.

The corresponding go generate commands are:

go-fuzz/go-fuzz/main.go

Lines 23 to 26 in 1810d38

	//go:generate go build github.com/dvyukov/go-fuzz/go-fuzz/vendor/github.com/elazarl/go-bindata-assetfs/go-bindata-assetfs
	//go:generate ./go-bindata-assetfs assets/...
	//go:generate goimports -w bindata_assetfs.go
	//go:generate rm go-bindata-assetfs

I tried a couple different flavors of go-bindata.

Based on comparing the output results, I suspect the most recent go generate run by @josharian in 1e7aea5 was using https://github.com/kevinburke/go-bindata, but not 100% sure. (The older https://github.com/jteeuwen/go-bindata seems pretty clearly not to be the flavor that was used).

If you are starting in a clean environment with a copy of dvyukov/go-fuzz, then this seems to work for me:

go get -u github.com/kevinburke/go-bindata/...
go get -u golang.org/x/tools/cmd/goimports
go get -u golang.org/x/tools/cmd/stringer
cd dvyukov/go-fuzz/go-fuzz
go generate

Part of the context here is that at the time I was looking into what it would take to embed the support packages into the binaries (#252).

I haven't dived very deeply here, so sorry in advance if this is incorrect.

[josharian]

It seems entirely plausible that I used https://github.com/kevinburke/go-bindata by mistake. I had been experimenting with various forks and ideas around that time. (One idea was to use DATA asm instructions for zero-cost readonly []byte embedded data.)

I don’t feel strongly at all about which bindata generator we use. Most are geared towards net/http etc and are serious overkill for go-fuzz, which only needs a few constant strings.

Actually, I wonder whether using txtar would be better. Then there’s no generate step at all—you just edit and use.

Anyway, feel free to make an executive decision, document it / use it as appropriate, and forge ahead.

[josharian]

I wonder whether using txtar would be better.

Or even just a few plain ol' Go const strings. There aren't many of these files, they're short, etc.

[tdakkota]

So, Go 1.16 is released. You can use now //go:embed.

[josharian]

Good point. But since go-fuzz will soon be replaced by the standard library, I’m inclined not to change things—and require 1.16—at this point.