Add js to generic build.

[dmitshur]

Fixes gopherjs/gopherjs#378. /cc @kaustavha

I've tested, and its TestGolden passes using gopherjs compiler after this change:

crc32 $ go test -v
=== RUN   TestGolden
--- PASS: TestGolden (0.00s)
=== RUN   ExampleMakeTable
--- PASS: ExampleMakeTable (0.00s)
PASS
ok      github.com/klauspost/crc32  0.005s

crc32 $ gopherjs test -v
crc32.go:157:10: undeclared name: updateCastagnoli
crc32.go:159:10: undeclared name: updateIEEE
crc32.go:182:48: undeclared name: updateIEEE

crc32 $ nano crc32_generic.go

crc32 $ gopherjs test -v
gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.
=== RUN   TestGolden
--- PASS: TestGolden (0.01s)
PASS
warning: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md
ok      github.com/klauspost/crc32  0.276s

[klauspost]

This is not your fault (it is like this in the Go sources), but a positive list for the fallback is silly.

Could you check if this works:

// +build !amd64,!amd64p32 appengine gccgo

If it does, let's change this line to this instead.

[dmitshur]

This is not your fault (it is like this in the Go sources), but a positive list for the fallback is silly.

Agreed. I wanted to do that too.

I'll try what you suggested and confirm it works.

[dmitshur]

Ok, I've tested that, and it works for gc (darwin, amd64) and gopherjs (darwin, js) environments:

crc32 $ go test -v
=== RUN   TestGolden
--- PASS: TestGolden (0.00s)
=== RUN   ExampleMakeTable
--- PASS: ExampleMakeTable (0.00s)
PASS
ok      github.com/klauspost/crc32  0.018s
crc32 $ gopherjs test -v
gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.
=== RUN   TestGolden
--- PASS: TestGolden (0.02s)
PASS
ok      github.com/klauspost/crc32  0.587s

The total set of build tags used across all files is quite complex, and I'm not completely confident that every single scenario is covered correctly.

But I'll update the PR. I've also cleaned up the style of build tags to be more idiomatic and consistent.

[klauspost]

The total set of build tags used across all files is quite complex, and I'm not completely confident that every single scenario is covered correctly.

Thanks for testing. At least with this change, we "only" have to exclude the known optimized functions, and white-list all non-optimized platforms.

If you update the PR, I will merge it, and take the blame if it doesn't work :)

[dmitshur]

I've updated, PTAL.

[klauspost]

Why are you moving these?

[dmitshur]

It's more idiomatic Go style and consistent with how build constraints are done.

Compare with:

• https://github.com/golang/go/blob/go1.5.3/src/runtime/cputicks.go
• https://github.com/golang/go/blob/go1.5.3/src/runtime/cgo/gcc_signal_darwin_lldb.c
• https://github.com/golang/go/blob/go1.5.3/src/crypto/sha1/sha1block_generic.go
• https://github.com/golang/go/blob/go1.5.3/src/crypto/sha256/sha256block_decl.go

It's just a style change and should not have any effect. If you dislike it, I can remove this commit.

[klauspost]

No problem. Thanks for the contribution!