Using Makefile(s) for Go
I&#x27;ve seen a lot of developers, especially developers with C backgrounds, reach for Makefiles when approaching Go development, and I think it&#x27;s a harmful practice. So, I&#x27;d like to offer a respectful but firm rebuttal to this article. :)<p>I dislike using make(1) with Go for two reasons.<p>The first is that make was developed for building C projects, and therefore is oriented around that task. Building C projects is a lot different than building Go projects, and it involves stitching together a lot of pieces, with plenty of intermediate results.<p>make(1) has first class support for intermediate results, which are expressed as targets.<p>If you look at the article, the author has to use a workaround just to avoid this core feature of make(1).<p>The second reason I dislike using make(1) for Go projects is that it harms portability.<p>A Go project should only require the Go compiler to build successfully. Go projects that need make(1) to build will not work out of the box for Windows users, even though Go is fully supported on Windows. For me, this puts Makefiles into the &quot;nonstarter&quot; category, even though I do all of my own development work on Linux. There is just no reason to complicate things for people who don&#x27;t have make(1) installed.<p>For code generation and other ancillary tasks, Go includes the &#x27;go generate&#x27; facility. This feature was created specifically to free developers from depending on external build tools. (<a href="https:&#x2F;&#x2F;blog.golang.org&#x2F;generate" rel="nofollow">https:&#x2F;&#x2F;blog.golang.org&#x2F;generate</a>)<p>For producing several binaries for one project, use several different main packages in directories that are named what you want your binary to be.<p>Edit: corrected some terminology.