Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/text/cmd/gotext: generate for one GOOS/GOARCH from a different GOOS/GOARCH #37846

Open
zx2c4 opened this issue Mar 13, 2020 · 9 comments
Open
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@zx2c4
Copy link
Contributor

zx2c4 commented Mar 13, 2020

I maintain a Go program for Windows that uses CGo, but I mostly develop from Linux. I use gotext, which means a file has in it:

//go:generate go run golang.org/x/text/cmd/gotext -srclang=en update -out=zgotext.go -lang=en,fr,ja,sl

The problem is that in order for gotext to look at the right source files, GOOS=windows and CGO_ENABLED=1 must be set. However, that causes go run to generate executables for Windows, not my Linux host system.

I've tried variations of -tags=windows without GOOS being set, but that doesn't work either.

Any advice?

cc @rozmansi @mpvl @bcmills

@smasher164 smasher164 changed the title gotext: generating on cross-archs x/text/cmd/gotext: generate for all GOOS/GOARCH Mar 13, 2020
@gopherbot gopherbot added this to the Unreleased milestone Mar 13, 2020
@smasher164 smasher164 added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 13, 2020
@zx2c4 zx2c4 changed the title x/text/cmd/gotext: generate for all GOOS/GOARCH x/text/cmd/gotext: generate for one GOOS/GOARCH from a different GOOS/GOARCH Mar 13, 2020
@zx2c4
Copy link
Contributor Author

zx2c4 commented Mar 13, 2020

The basic problem here is a slightly more lower level one -- passing one GOOS to go run and another one to whatever is running. Might be up the alley of @ianlancetaylor and @bcmills

@zx2c4
Copy link
Contributor Author

zx2c4 commented Mar 13, 2020

For example go build -o out golang.org/x/text/cmd/gotext && CC=x86_64-w64-mingw32-gcc GOOS=windows CGO_ENABLED=1 ./out -srclang=en update -out=zgotext.go -lang=en,fr,ja,sl seems to work, but does not mesh well with //go:generate tags obviously.

@alexbrainman
Copy link
Member

@zx2c4 can you use generate build tag?

#31920 (comment)

https://go-review.googlesource.com/c/go/+/175983/

Alex

@zx2c4
Copy link
Contributor Author

zx2c4 commented Mar 14, 2020

Not sure that will help. The issue is that go run sticks its target through the Go build system, but gotext also sticks the whole project through the build system in order to extract strings and such. When gotext does that, it should be with GOOS=windows,CGO_ENABLED=1, but when go run builds gotext and executes it, it should be building the tool with the default GOOS/CGO_ENABLED.

@bcmills
Copy link
Contributor

bcmills commented Mar 14, 2020

As a workaround, perhaps your //go:generate line could go run a second binary that itself builds gotext and then runs it with an appropriate environment?

@zx2c4
Copy link
Contributor Author

zx2c4 commented Mar 14, 2020

That works, but winds up being really ugly: https://git.zx2c4.com/wireguard-windows/tree/gotext.go?id=2a211c5d1248774996f24e50067400326fd91a05

I don't like duplicating the build environment variables inside of that, or having to pick a temporary directory for doing that building.

Seems like gotext ought to have a better way here...

@myitcv
Copy link
Member

myitcv commented Mar 14, 2020

#27898 is potentially related

@alexbrainman
Copy link
Member

Not sure that will help.

You are correct, I don't see how it will solve your problem.

Alex

@metux
Copy link

metux commented Sep 30, 2023

Looks like a typical cross compiling situation where BUILD- and HOST-tools need to be separated.
autoconf does that by having separate namespaces for toolchain related variables.

In that case, anything that builds programs to be run within the build process needs to use different variables than for programs to be run on the target system (BUILD vs HOST in GNU nomenclature).

Example:

  • go generate will use BUILD_GOARCH/BUILD_GOOS
  • if not set, it will guess them from currently running system (eg uname, etc)
  • the output programs will be run only within build process, but never installed anywhere

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants