3 ms·
Well, it's more than just dependencies. `go generate` isn't meant to be involved at all if you're just building a package or command for using it, which is quit
by dsymonds 12y ago
Well, it's more than just dependencies. `go generate` isn't meant to be involved at all if you're just building a package or command for using it, which is quite a bit different to `make`.
- jerf 12y agoNow put those two together, and you can understand what the idea here is: It doesn't do dependencies and it isn't meant for end users, only package authors. The Go philosophy is that if you truly need a make file or other such system, use it. It's always been that way, actually; if you poke hard enough you can still find old Go tutorials which require you to use make (or some other build tool). But if you need it for just this simple little thing, you shouldn't have to pull in make, just as the developing Go philosophy is that it is silly to pull in entire packages for one little function. The purpose of "go generate" is not to replace make; it is to close out another 80% of the uses of make (my made-up number) by offering a simple, high bang-for-the-buck addition that can be depended on in the base language. Some projects will still need make. This expands the set that don't. There's no interest in trying to make this grow to include all things that use make. It fits the pragmatic philosophy of Go.