3 ms·

So I saw this and thought why not give it a try. How hard could it be right? My goal? Take my bash file that does just this (I started go just yesterday so I mi

by nstart 9y ago

So I saw this and thought why not give it a try. How hard could it be right? My goal? Take my bash file that does just this (I started go just yesterday so I might be doing cross compiling wrong :D) : ``` export GOPATH=$(pwd) export PATH=$PATH:$GOPATH/bin go install target/to/build export GOOS=darwin export GOARCH=amd64 go install target/to/build ``` which should be simple. Right? Set environment variables, run a command. Set another environment variable, run a command. 45 minutes in and I haven't been able to quite figure it out just yet. I definitely figured out how to write my build.sh files in less than 15 minutes for sure when I started out.

JacksCracked 9y ago
Each logical line of a makefile is executed in its own shell. This means that variables cannot be set across lines and directory changes cannot be changed across lines.
- ComputerGuru 9y ago
  Just use the export command to set variables across lines.
sethammons 9y ago
Aside: for Go, just set your GOPATH and such once. Like ~/go. And never touch it again. You now can 'go get' any packages you need. When you set your package up for source control, its root will be (say, for a github package) $GOPATH/src/github.com/your-account/your-package. When you want to work on that package, you cd to that directory, and manage it there. This is why many who use Go don't get all the fuss with makefiles that some folks insist on. You just go to your project directory and 'go test' or 'go build' or whatnot. Simple. No need to 'make test' or 'make build' unless you have some strange, complicated set up.
wink 9y ago
Here's what I use: https://github.com/wywy/check-bucket-size/blob/master/Makefile https://github.com/wywy/check-bucket-size/blob/master/Makefi...
majewsky 9y ago
Here's my current pattern for Makefiles: https://github.com/sapcc/swift-drive-autopilot/blob/3eceb4e0b63732b962531ca1216c332f34395552/Makefile https://github.com/sapcc/swift-drive-autopilot/blob/3eceb4e0... It uses a private GOPATH inside the repo, created by: $ cd /path/to/repo $ mkdir -p .gopath/src/github.com/username $ ln -s ../../../.. .gopath/src/github.com/username/projectname With this you can run `go build` etc. with `GOPATH=/path/to/repo/.gopath` and it will work regardless of where the repo is checked out, and you can also `go get` the repo into the normal `GOPATH`. It's the best of both worlds, in a way. A Go developer can use `go get` etc. and everything works as he expects. A distro packager can grab a release tarball, unpack it in some random place and do `make && make check && make install DESTDIR=/tmp/build` as she expects.

by nstart 9y ago

JacksCracked 9y ago

Each logical line of a makefile is executed in its own shell. This means that variables cannot be set across lines and directory changes cannot be changed across lines.

ComputerGuru 9y ago
Just use the export command to set variables across lines.

sethammons 9y ago

Aside: for Go, just set your GOPATH and such once. Like ~/go. And never touch it again. You now can 'go get' any packages you need. When you set your package up for source control, its root will be (say, for a github package) $GOPATH/src/github.com/your-account/your-package. When you want to work on that package, you cd to that directory, and manage it there. This is why many who use Go don't get all the fuss with makefiles that some folks insist on. You just go to your project directory and 'go test' or 'go build' or whatnot. Simple. No need to 'make test' or 'make build' unless you have some strange, complicated set up.

wink 9y ago

Here's what I use: https://github.com/wywy/check-bucket-size/blob/master/Makefile https://github.com/wywy/check-bucket-size/blob/master/Makefi...

majewsky 9y ago

Here's my current pattern for Makefiles: https://github.com/sapcc/swift-drive-autopilot/blob/3eceb4e0b63732b962531ca1216c332f34395552/Makefile https://github.com/sapcc/swift-drive-autopilot/blob/3eceb4e0... It uses a private GOPATH inside the repo, created by: $ cd /path/to/repo $ mkdir -p .gopath/src/github.com/username $ ln -s ../../../.. .gopath/src/github.com/username/projectname With this you can run `go build` etc. with `GOPATH=/path/to/repo/.gopath` and it will work regardless of where the repo is checked out, and you can also `go get` the repo into the normal `GOPATH`. It's the best of both worlds, in a way. A Go developer can use `go get` etc. and everything works as he expects. A distro packager can grab a release tarball, unpack it in some random place and do `make && make check && make install DESTDIR=/tmp/build` as she expects.