3 ms·

I just set the $GOPATH per project and it stops being a big problem, and turns into just an inconvenience. If you have a ProjectX with the path $pathx, set $GO

by patates 10y ago

I just set the $GOPATH per project and it stops being a big problem, and turns into just an inconvenience. If you have a ProjectX with the path $pathx, set $GOTPATH to $pathx and place your source files in $pathx/src/projectx I also hate that I have to do this though and I totally understand what you mean. Just wanted to mention my favorite work-around to see if I get some feedback on it being stupid/clever/ordinary.

shakna 10y ago
It's what I've been recommended, but it really seems like a terrible hack that shouldn't have to exist.
- 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.

by patates 10y ago

shakna 10y ago

It's what I've been recommended, but it really seems like a terrible hack that shouldn't have to exist.

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.