4 ms·

But again, you can do that with Go very easily. eg the -pkgdir flag in `go build`. You can also write your own wrapper script around Go build tools. Or even by

by laumars 10y ago

But again, you can do that with Go very easily. eg the -pkgdir flag in `go build`. You can also write your own wrapper script around Go build tools. Or even bypass `go build` entirely and call the Go compiler in the exact same way you'd described above (-o and -L flags included). Run `go build -n` against your project to see what `go build` does (it's print only mode, no compiling will happen) and you'll see it's really no different to what you were asking for So everything you want to do can and is supported by Go. It's just not it's default behaviour so you needed to do a little digging to find it. Personally though, I find the inconvenience of having to change GOPATH / GOOS / GOARCH to be significantly less annoying than having to write makefiles and configure scripts to handle every platform I might want to target. For most people `go build` abstracts away the pain of cross compiling and build scripts quite nicely. In fact that was one of the biggest reasons I started using Go in the first place (I wanted something I could rapidly code and compile on AMD64 then rsync onto ARM devices back when I was experimenting with building custom embedded devices for my car). edit: just want to add that I'm not under any illusion that Go nor it's tooling is perfect. I'm just saying Go can easily support your specific workflow preferences even though superficially it appears otherwise.

shakna 10y ago
> needed to do a little digging to find it. I would love some documentation on it. The Go developers hostility to the approach is hugely offputting.
- laumars 10y ago
  Go is well documented though. For example the stuff I posted earlier is available through `go help build`, the go command source files (eg https://golang.org/pkg/go/ https://golang.org/pkg/go/) and an online man page (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies https://golang.org/cmd/go/#hdr-Compile_packages_and_dependen...). I'd recommend you read the latter page first. If you don't mind me saying, maybe some of the hostility is because you keep saying Go "cannot" do x, y or z without looking at said documentation first? I know I've gotten terse responses from the community in the past when I've asked questions that were already well explained in the docs. I agree it's not nice being on the receiving end of such responses but I can also sympathise with why the community get sick of answering basic questions that are already available in a simple Google / DuckDuckGo search.
  - shakna 10y ago
    Not any personal hostility. Rather [0]: > 1) ... The $GOPATH provides us with a place to store common, shared third party libs on our system, and our own projects. > #1 is the correct and supported way. The other methods are actively discouraged. Andrew. But, for example, the documentation for GOPATH makes no suggestion it is even possible [1]: > GOPATH must be set to get, build and install packages outside the standard Go tree. > Each directory listed in GOPATH must have a prescribed structure: And the compiler help says: > Build adheres to certain conventions such as those described by 'go help gopath'. It's exciting that I've been mislead about the ease of this, but I wouldn't say it is well explained in the docs. The team want one true way of building a go pkg. [0] https://groups.google.com/forum/#!topic/golang-nuts/dxOFYPpJEXo https://groups.google.com/forum/#!topic/golang-nuts/dxOFYPpJ... [1] https://golang.org/cmd/go/#hdr-GOPATH_environment_variable https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
    - laumars 10y ago
      I don't really know how to respond because I found the answers you wanted by looking briefly in the docs. > But, for example, the documentation for GOPATH makes no suggestion it is even possible [1] Well to be fair you were looking for information about compiler flags in the documentation for the envvars; which perhaps wasn't the best systematic approach to research your problem? But hopefully you now have the information you need? Or at least better idea of how to find the answers you seek? >The team want one true way of building a go pkg. This is very true. However as long as your code follows the same standards it doesn't really matter how you chose to organise your source files as it should still compile on other people's systems using `go build` in the idiomatic way. And for what it's worth, a lot of people don't follow the directory hierarchy in the strictest way and/or use `go build/install`; choosing instead to use their preferred vendoring system. So I doubt many people would have a problem if you wanted to do your own thing just so long as the code is still compatible with Go's standard build tools should you release your projects to the world.

by laumars 10y ago

shakna 10y ago

> needed to do a little digging to find it. I would love some documentation on it. The Go developers hostility to the approach is hugely offputting.

laumars 10y ago
Go is well documented though. For example the stuff I posted earlier is available through `go help build`, the go command source files (eg https://golang.org/pkg/go/ https://golang.org/pkg/go/) and an online man page (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies https://golang.org/cmd/go/#hdr-Compile_packages_and_dependen...). I'd recommend you read the latter page first. If you don't mind me saying, maybe some of the hostility is because you keep saying Go "cannot" do x, y or z without looking at said documentation first? I know I've gotten terse responses from the community in the past when I've asked questions that were already well explained in the docs. I agree it's not nice being on the receiving end of such responses but I can also sympathise with why the community get sick of answering basic questions that are already available in a simple Google / DuckDuckGo search.
- shakna 10y ago
  Not any personal hostility. Rather [0]: > 1) ... The $GOPATH provides us with a place to store common, shared third party libs on our system, and our own projects. > #1 is the correct and supported way. The other methods are actively discouraged. Andrew. But, for example, the documentation for GOPATH makes no suggestion it is even possible [1]: > GOPATH must be set to get, build and install packages outside the standard Go tree. > Each directory listed in GOPATH must have a prescribed structure: And the compiler help says: > Build adheres to certain conventions such as those described by 'go help gopath'. It's exciting that I've been mislead about the ease of this, but I wouldn't say it is well explained in the docs. The team want one true way of building a go pkg. [0] https://groups.google.com/forum/#!topic/golang-nuts/dxOFYPpJEXo https://groups.google.com/forum/#!topic/golang-nuts/dxOFYPpJ... [1] https://golang.org/cmd/go/#hdr-GOPATH_environment_variable https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
  - laumars 10y ago
    I don't really know how to respond because I found the answers you wanted by looking briefly in the docs. > But, for example, the documentation for GOPATH makes no suggestion it is even possible [1] Well to be fair you were looking for information about compiler flags in the documentation for the envvars; which perhaps wasn't the best systematic approach to research your problem? But hopefully you now have the information you need? Or at least better idea of how to find the answers you seek? >The team want one true way of building a go pkg. This is very true. However as long as your code follows the same standards it doesn't really matter how you chose to organise your source files as it should still compile on other people's systems using `go build` in the idiomatic way. And for what it's worth, a lot of people don't follow the directory hierarchy in the strictest way and/or use `go build/install`; choosing instead to use their preferred vendoring system. So I doubt many people would have a problem if you wanted to do your own thing just so long as the code is still compatible with Go's standard build tools should you release your projects to the world.