current community

your communities

more stack exchange communities

Stack Exchange
tour help
careers 2.0
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 0 down vote favorite

I'm cross compiling Golang programs on Windows for Linux, using:

go build -o myprog.bin myprog.go

To do so I have to set the environment variable GOOS=linux. As I'm also compiling some programs for windows, when I'm done with the cross compile I have to reset GOOS=windows. So I have a batch file as follows:

set GOOS=linux
go build -o myprog.bin myprog.go
set GOOS=windows

If I happen to be compiling two programs for each Linux and Windows simultaneously, the windows program may get compiled for Linux. Is there a way to limit the scope of an environment variable to a command on windows, or to override it for a command? eg

go build -o myprog.bin myprog.go -GOOS linux

I know goxc provides this, but can go build?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

To build upon Greg's answer which explains that changes using the set command are limited to the process, if you want to limit scope of environment variable changes within a process, use the setlocal and endlocal commands. This allows you to isolate variables within a single command process.

setlocal
set GOOS=linux
go build -o myprog.bin myprog.go
endlocal
:: GOOS will now equal what it was before being set within the scope
share|improve this answer
    
This is what I was getting at, although I was hoping I could just pass the os to the go build command in a one liner. setlocal && set GOROOT=C:\Go\Test\ && echo %GOROOT% && endlocal isn't run sequentially. I guess goxc is the tool for the job. –  10 cls Feb 17 at 14:06
up vote 1 down vote

Environment variables are local to the process in which they are set (and descendants of that process). So when you do set GOOS=linux, the change happens only within that command processor and doesn't affect any other existing processes. New processes started from within that command processor inherit the current values of its environment variables.

So in short, your solution of set GOOS=linux followed by set GOOS=windows will work fine, and there is no risk of that interfering with other simultaneous builds.

share|improve this answer
    
If I set GOROOT=x at the command prompt, then at the start of a script set GOROOT=y, when the script exits echo %GOROOT% displays y, which suggests to me that based on your answer GOOS and GOROOT are different kinds of environment variables. Is that right? –  10 cls Feb 17 at 1:43
    
Setting an environment variable within a script affects the value of the environment variable for that command prompt after the script exits (this is different behaviour from Unix-like systems). –  Greg Hewgill Feb 17 at 1:48
    
Ok, that might be worse. The scripts don't have to be simultaneous, just run from the same prompt. So they're not limited to the command unless the command is in a the only thing run from that prompt, or in a batch file run from windows. Sounds like the way to go would be set GOROOT=y && go build... && set GOROOT=x but it's 2am here, I'll pick this up later. Thanks. –  10 cls Feb 17 at 2:11
    
To solve that, your build scripts should not rely on the value of any pre-existing environment variables that might have been changed by a previous run of a script. –  Greg Hewgill Feb 17 at 2:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.