Hacker News new | ask | show | jobs
by majewsky 2386 days ago
You make it sound like `go install` and `go test` are the only things you're ever going to run in a Go repository. This is blatantly untrue. For example, these are the invocations for the test suite for one of my Go programs:

https://github.com/sapcc/limes/blob/364317fa9a25065bcf9384c8...

Why should I have to enter all of this manually every single time?

(And before you argue that gofmt, golint and go vet run in the editor if you've set it up properly: That's true, and that's how I have my editor set up. That part of the test is to catch the external contributors that don't.)

> The second reason I dislike using make(1) for Go projects is that it harms portability. A Go project should only require the Go compiler to build successfully.

For many of my projects, a Makefile is the main reason why repos work with `go get` at all. I use `make` which prepares all the generated files and non-Go artifacts (typically bundled into `bindata.go`), so that I can commit these in the repo. Then when a user comes along, they can `go get` the application because all the bespoke compilation steps have already been done by me via my Makefile. An example of this: https://github.com/majewsky/alltag/blob/df161b55fa4c7eba0abe...