The title mostly says it. I know that I can do
set GOOS=linux
set GOARCH=amd64
in cmd before I go build, but I'm trying to write a build script and do it all with exec.Command.
My go build -o etc works with exec.Command (it builds), but when printing out GOOS in a test script after either of this commands:
cmd := exec.Command("set", "GOOS=linux")
// OR
cmd := exec.Command("set GOOS=linux")
I get windows.
Any ideas? Thanks!
I strongly suggest you just use a tool like Gox instead. It cross-compiles into every supported build target by just executing gox. It also has options if you only want to build for certain targets.
As for the code you're asking about, exec.Command doesn't create a new process, or really do anything other than create a Cmd struct. The os/exec documentation (specifically the docs for the Command function) has an example of what you seem to be trying to do- execute another program with custom environment variable assignments... see the Example (Environment) section of the linked documentation and try to follow that structure if you still want to cross-compile your way.
Related
I'm just starting with the new programming language Zig and finding documentation pretty sparse.
I can build and run the current project by invoking zig build run.
I can also do zig run src/main.zig assuming standard project layout.
But in neither case can I find a way to pass along commandline arguments to my project.
I know that after building I can invoke my project as a binary as zig-out/bin/<my project's name> foo bar but is there a way to do it straight from build run?
Just trying the obvious zig build run foo bar tells me Cannot run step 'foo' because it does not exist.
None of the commandline switches for zig itself seem to do what I want and I can't find anyone discussing this by Googling for it.
just pass your arguments after -- (zig build run -- <args>)
e.g:
zig build run -- foo bar
I tried to run the program in command prompt #Go lang- But when i type run "go run hello.go" command i am gettin
CreateFile hello.go:The system cannot find the file specified
Please help to to compile and run the above marked program, Thanks in advance
As you can see from the output of running the dir command
earlier up in your shell session, there is indeed no file named "hello.go"
in the C:\GOCODE\testproject directory.
When you execute the
go run hello.go
command, the go tool tries to find the file named "hello.go" in the current
directory (because the name of that file is relative, so it's being
searched in current working directory). There's no such file,
and that's what go run tells you.
Unfortunately, from the outlook of your shell session, it appears there
are more problems with your setup.
And there are problems with your approach to Go.
First, while it looks like you're following
this guide (and this is the right thing
to do, actually), you misread it.
What it tried to tell you is that you should create the "src"
directory (and then the "hello" directory to contain your test project)
in the so-called workspace, and a list of workspaces known to Go
is stored in the GOPATH environment variable.
As you can see from the go env output, Go thinks you have a single
workspace located in C:\Users\Sitaram\Go.
Now it worth reiterating that—contrary to many (if not most) "mainstream"
languages,—Go is not "project-based"; instead, it requires all your code
to be organized in those workspaces, and it wants to know where these
workspaces are.
By default—if you did not explicitly set the GOPATH environment
variable,—it assumes your single workspace is located in the directory
named "go" placed in your "home folder".
And that's what you see in the go env output.
Now you have two options:
Set the GOPATH env. variable for your user to C:\GOCODE
then start another shell—so that it "sees" that variable and allows
the go tool to also see it and use).
Run go env to verify GOPATH contains C:\GOCODE.
Then follow the rest of the tutorial document:
Make sure there is the "src" folder directly under the C:\GOCODE.
Create your project folder directory under "src".
Let's say, it will be named "hello".
Under "hello", create that "hello.go" file.
Now cd C:\GOCODE\src\hello and then go build — you will have
the hello.exe created there.
Don't mess with GOPATH and just repeat the steps 2-4 from above
in the default workspace—C:\Users\Sitaram\go.
I'd go with the second variant because that inexplicable affection
of certain Windows users for polluting the C:\ with random personal
data is really an anti-pattern; have your personal belongings in your home
folder! Windows has gone a long way getting that right; and almost all
Windows software is finally there—understanding that paradigm. So why deviate?
Second, please unlearn go run.
I'm not sure the Go developers actually regret implementing it,
but people do really misinterpret what this tool is for.
It's for one-off throw-away "scripts".
Real development is done using go install and, sometimes, go build.
In most cases your normal development routine you use go install
exclusively — as it caches the results of compilation of all the packages
your project depends on. go build does not do this, and go run does
not even preserve the result of the compilation of your project itself.
Please read this quick reference card for more info.
After go get gpackage check if there is a yourproject.exe in your bin directory to compile your github package with your project.
If not, you have to do cd src/yourproject and type go install and hit enter.
Try execute the folowing command e check if corrected:
go env -w GOOS=windows
I am creating a desktop Windows application in Go. Currently I use this line to install it:
go install -ldflags -H=windowsgui
I want users to be able to just say
go get github.com/my/app
and automatically have the windowsgui flag specified for building. Is it possible to add the flag as a code comment, like #cgo comments. Or would I have to provide a make file in the project directory like in the old days of Go? Or is it not possible at all?
Bad news, you can't.
Semi-good news, you can tell your users to use go get -ldflags "-H windowsgui" github.com/my/app on Windows.
I'm trying to set up haxe development environment. I'd prefer not to install haxe in /usr, so I edited haxe Makefile so that the install directory is a local one:
INSTALL_DIR=/home/liori/Programy/haxe.install
However, now I cannot use haxelib:
% PATH=/home/liori/Programy/haxe.install/bin:$PATH haxelib setup /home/liori/Programy/haxe.install/haxelib
Standard library not found
How to execute haxelib in these circumstances?
Since the error mentioned "Standard library not found", probably the "std" folder is misplaced somehow.
The haxe standard lib folder, "std", should be placed right next to the "haxe" executable. If you want to have an alternative setup, you should set up an env variable, HAXE_STD_PATH, which points to the "std" folder. Try set it up and run haxelib again.
If that still doesn't work, try to open the haxelib executable in a text editor, it should be a script that runs haxe. See if any of the arguments is wrong.
Yet another option is to make haxelib, which will produce a compiled haxelib executable instead of the script based one.
I've included the net/http/pprof package in my code. I can then comfortably run the pprof profiler (on Debian):
go tool pprof http://localhost:9000/debug/pprof/profile
Commands such as top10 or even generating call graphs work as expected. However, as soon as I try to go into a function, it fails:
(pprof) list MyFunc
No source information for mypkg.MyFunc
My GOPATH is set to my project's directory. Do I need any special flags or environment variables while building my source code or while running pprof?
Found the answer with the help of the golang-nuts people. I needed to specify the binary:
go tool pprof mybinary http://localhost:9000/debug/pprof/profile
This way the source code is found and can be listed with the "list" command.
I had the same problem with "net/http/pprof", albeit on windows.
Using "runtime/pprof" instead, with pprof.StartCPUProfile / StopCPUProfile solved it.