Closed rsc closed 4 years ago
Thanks Russ and apologies for the delayed response. The intention you described is correct:
it looks like the intent was for dom_wasmjs_gopherjs.go to apply to js/wasm builds and dom_native.go to apply otherwise.
However, it misses one point which was that we are also intending here to support the GopherJS compiler which does not set the wasm
build tag. Thus your suggestion go1.12 && js && wasm
:
// +build go1.12,js,wasm
Would work in the case of GOOS=wasm GOARCH=js go build
but not in the case of gopherjs build
which doesn't set the wasm
build tag.
You are right that this is true:
dom_wasmjs_gopherjs.go
:(go1.12 && wasm && js) || js
which is a complex way of writingjs
.
I wrote it this way in hopes of being a bit more explicit:
(go1.12 && wasm && js)
-> GOOS=wasm GOARCH=js go build
"with Go 1.12+ only"js
-> gopherjs build
"with any version, because only Go 1.11 is (was) supported in GopherJS"But given this issue I presume that just js
and a comment would've been better perhaps :)
(A bit unrelated, but this is another example of why https://github.com/gopherjs/vecty/issues/264 is probably a good call at this point.)
I've been analyzing
// +build usage
in the Go ecosystem and turned up dom_wasmjs_gopherjs.go, which says:and dom_native.go which says:
These two conditions are:
dom_wasmjs_gopherjs.go:
(go1.12 && wasm && js) || js
which is a complex way of writingjs
. dom_native.go:go1.12 && !wasm && !js
I am unsure about what exactly is intended here. From the comments in dom_native.go, it looks like the intent was for dom_wasmjs_gopherjs.go to apply to js/wasm builds and dom_native.go to apply otherwise. That would be:
dom_wasmjs_gopherjs.go:
go1.12 && js && wasm
dom_native.go:
!(go1.12 && js && wasm)
which is!go1.12 || !js || !wasm
Best, Russ