3 ms·

It's not really any different to supplying the source paths in C / C++ build scripts. Or setting the Java variables in your preferred IDE. At the of the day the

by laumars 10y ago

It's not really any different to supplying the source paths in C / C++ build scripts. Or setting the Java variables in your preferred IDE. At the of the day the compiler isn't going to know where to import external source files from if you don't specify it somewhere. The GOPATH envvar just shortcuts the need to use build flags but if you want to do away with system wide Go variables then you can always write build scripts more akin to those we see in some other languages.

shakna 10y ago
$(CC) $(FILES) -L$(LIBS) -o $(EXE) Allows me to change and modify on a per project basis how to compile a program. In fact, it allows me to change exactly how it's compiled or cross-compiled. I can use system libs if available, and if not, drag down the latest, build that locally, and link locally. Go isn't as flexible. It's opinionated. There doesn't seem to be any benefit other than standards compliance in having a GOPATH. I have to circumvent how Go wants to work so that it can fit with the standards I have that C, C++, C#, F#, Haskell, D, Nim, Red, Chicken, Python all work with without being bashed into submission, they supply tools to make it easier. They don't have lead developers standing up and saying "All Python libraries should be developed in this particular folder structure. Even if it makes integrating C code more difficult." That feels... Wrong. So repeatedly setting GOPATH sucks, and can cause havoc if the envar isn't released properly by, say, a failing build. But, as I said to start with: This is a tiny knitpick. It means I come back and try Go, time and again. It also means I spend more time wrestling Go into submission within my automated testing and deployment structures, than writing code in it.
- 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

by laumars 10y ago

shakna 10y ago

$(CC) $(FILES) -L$(LIBS) -o $(EXE) Allows me to change and modify on a per project basis how to compile a program. In fact, it allows me to change exactly how it's compiled or cross-compiled. I can use system libs if available, and if not, drag down the latest, build that locally, and link locally. Go isn't as flexible. It's opinionated. There doesn't seem to be any benefit other than standards compliance in having a GOPATH. I have to circumvent how Go wants to work so that it can fit with the standards I have that C, C++, C#, F#, Haskell, D, Nim, Red, Chicken, Python all work with without being bashed into submission, they supply tools to make it easier. They don't have lead developers standing up and saying "All Python libraries should be developed in this particular folder structure. Even if it makes integrating C code more difficult." That feels... Wrong. So repeatedly setting GOPATH sucks, and can cause havoc if the envar isn't released properly by, say, a failing build. But, as I said to start with: This is a tiny knitpick. It means I come back and try Go, time and again. It also means I spend more time wrestling Go into submission within my automated testing and deployment structures, than writing code in it.

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