5 ms·
I don't understand the GOPATH criticism. For your C compiler to find included header files they need to be specified relative to /usr/include (or some other pat
by slrz 9y ago
I don't understand the GOPATH criticism. For your C compiler to find included header files they need to be specified relative to /usr/include (or some other path contained in the list searched by your compiler).
For the go build tool to find Go packages they need to be given relative to (an element of) GOPATH (which is a colon-separated list of directories that is searched for Go package sources). To work on your own code inside your home directory while installing other packages using Homebrew, you'd set a GOPATH of $HOME:/usr/local. If you also want to consider packages shipped with the OS, you append a ":/usr" to that.
Lots of things work this way: @INC in Perl, sys.path in Python and many more. Why have people such issues understanding this concept when it's called GOPATH?
- iainmerrick 9y agoIf I have a hello.c and hello.h in the same directory, and hello.c #includes "hello.h", I can "cc hello.c" and it always works just fine. In Python, you have to add some empty __init__.py files to your project, but once you've done that, local imports work just fine, no environment variables needed. GOPATH is unusual and not like other programming languages. Once again, the two major use cases for imports are "stuff local to my project" and "stuff I've installed". GOPATH covers a third case, "other packages I want to use, that I haven't installed and haven't vendored". That doesn't seem important enough to warrant making "stuff local to my project" irritatingly fiddly. If I download some Go program from Github, even if it has all its dependencies vendored, it doesn't work unless I put it in ~/go or set GOPATH. That's strange! Why wouldn't you want it just to work out of the box, wherever you put it?