17 ms·

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/pk

by 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

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.