4 ms·
Ech. I will prefer GOPATH over the hell that are C/C++ include paths any day of the week. How many are there on a modern Linux system? Six? Holy hell, it's eig
by ainar-g 8y ago
Ech. I will prefer GOPATH over the hell that are C/C++ include paths any day of the week. How many are there on a modern Linux system? Six?
Holy hell, it's eight!
$ gcc -xc++ -E -v -
#include <...> search starts here:
/usr/include/c++/7
/usr/include/x86_64-linux-gnu/c++/7
/usr/include/c++/7/backward
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
- sseth 8y agoUnfortunately, the GOPATH structure makes it harder to mix golang projects with other languages when you need to. And it does not support package versions. I think the time has come to say goodbye to GOPATH. Does not mean of course that include paths are better.
- masklinn 8y agoI'm not sure I see the difference. $GOPATH can be a list, all this tells you is that C and C++ libraries come from various sources (system, compiler, package manager, …), you could have the exact same crap in your system-provided GOPATH if there was such a thing.
- majewsky 8y agoWell, you have a system-provided GOPATH, in GOROOT (on my system, the stdlib source is in /usr/lib/go/src). But you just surprised me: I never knew that GOPATH is a list.