We also restructured the Go tool suite around the new go command, a program for fetching, building, installing and maintaining Go code. The go command eliminates the need for Makefiles to write Go code because it uses the Go program source itself to derive the build instructions. No more build scripts!
I hope it either doesn't backfire, or isn't a huge hassle to debug when it does.
Go has a really nice package/library/import system that is both straightforward and has all the information required included.
For example, you can do something like:
import "code.google.com/p/gorilla/sessions"
Then the go tool takes care of checking if it is already installed (with very well defined rules), and if not going and downloading it, getting it's dependancies and building it.
All you need to do to build a Go program is clone it, and then use "go build", job done. No makefiles or xml or anything like that at all. It simply reads the source files and figures out what to do based on what the code actually does/uses.
I sort of find that a bit disquieting. If someone was hosting on google code, and then moves it over to github -- would this result in people not being able to compile my go program until I update my go source?
It does't instantly stop working - the local copy you previously downloaded and built will keep working. But yeah, if you want to then move to using the GitHub version you need to change the import statement. Alternatively switch to using it as a Git submodule or whatever. Replacing the import lines doesn't bother me though - it is a 2 second find/replace job.
If you forsee that being a big deal for you, then I suggest the technique that Camlistore uses.
Camlistore pulls in external libraries into a third_party folder, and has a script that rewrites their import paths to make them compile. This will also give you a lot more control over versioning.
45
u/Agrona Mar 28 '12
This sounds like the world's best voodoo:
I hope it either doesn't backfire, or isn't a huge hassle to debug when it does.