playground: Explicitly set GOARCH=js during go generate. #66
Conversation
This is needed after gopherjs/gopherjs#594 was resolved, because in Go 1.8, go generate sets GOARCH to source platform it's running on, but we want it to be either unset or GOARCH=js. This is very similar to issue gopherjs/gopherjs#601. Also use tabs rather than spaces for indentation (since it no longer aligns anyway).
|
@neelance Did you read the PR description or commit message, and it's still unclear? I can elaborate further, just want to make sure you didn't miss this:
Without this change, you'd get the following error: |
|
Yeah, I read it, but I didn't understand. Now that I looked again it is suddenly clear to me. ;-) But I have to say: Are we really sure that failing on a bad |
|
I'm not sure. I thought that users would only ever run into the issue if they explicitly set wrong GOARCH themselves. But that was before I found out that go generate always sets GOOS, GOARCH, etc. Given that GopherJS only supports one value for target architecture, and never will support other targets (presumably), ignoring GOARCH env var is a valid option too. But what do we do about GOOS? |
Exactly. Same here.
There is no issue with that, right? So keep it as is. |
This reverts commit 62bca28. We've originally discussed two possible fixes in issue #594: > The gopherjs tool does not use the GOARCH environment variable > in any way. Internally, GopherJS always uses js as GOARCH value > when compiling user code, but it does other internal stuff when > compiling standard library. > > 1. One fix is to make the gopherjs tool really ignore GOARCH env > var. In other words, setting it to any value should have no effect; > it shouldn't cause this failure. > > 2. We could also consider making it use the value of GOARCH, and > error out if it's set to anything other than js (which is the > default and the only supported value). Since gopherjs can't compile > for any other architectures. Upon further consideration, after seeing issue #601 and gopherjs/gopherjs.github.io#66, we've decided (see discussion in gopherjs/gopherjs.github.io#66 (comment)) to revisit this issue and change gopherjs to completely ignore GOARCH environment variable, instead of requiring it to be unset or equal to js. Closes #601. Updates #594.
This reverts commit 62bca28. We've originally discussed two possible fixes in issue #594: > The gopherjs tool does not use the GOARCH environment variable > in any way. Internally, GopherJS always uses js as GOARCH value > when compiling user code, but it does other internal stuff when > compiling standard library. > > 1. One fix is to make the gopherjs tool really ignore GOARCH env > var. In other words, setting it to any value should have no effect; > it shouldn't cause this failure. > > 2. We could also consider making it use the value of GOARCH, and > error out if it's set to anything other than js (which is the > default and the only supported value). Since gopherjs can't compile > for any other architectures. Upon further consideration, after seeing issue #601 and gopherjs/gopherjs.github.io#66, we've decided (see discussion in gopherjs/gopherjs.github.io#66 (comment)) to revisit this issue and change gopherjs to completely ignore GOARCH environment variable, instead of requiring it to be unset or equal to js. Closes #601. Updates #594.
|
This PR is no longer needed after gopherjs/gopherjs#605. Closing. |
This is needed after gopherjs/gopherjs#594 was resolved (/cc @bep), because in Go 1.8,
go generatesetsGOARCHto source platform it's running on, but we want it to be either unset orGOARCH=js.This is very similar to issue gopherjs/gopherjs#601 (/cc @DrJosh9000).
Also use tabs rather than spaces for indentation (since it no longer aligns anyway).
This was used locally to generate 37d9884.