I've seen a lot of developers, especially developers with C backgrounds, reach for Makefiles when approaching Go development, and I think it's a harmful practice. So, I'd like to offer a respectful but firm rebuttal to this article. :) I dislike using make(1) with Go for two reasons. The first is that make was developed for building C projects, and therefore is oriented around that task. Building C projects is a lot…
Why do people on this website use "make(1)" instead of "make" in writing? And I know it's in the man pages but what is this number even for?
Using Makefile(s) for Go
61–70 of 104 posts
Re: Using Makefile(s) for Go
#62Earlier quoted context omitted.
I agree. They claim `make` is simple, but it really isn't. PHONY targets are one example. Unfortunately I've looked for an alternative and didn't really find anything very good. I eventually settled on a Python 3 script. Python 3 is reasonably nice to use with type annotations. It doesn't require compilation and its speed is fine if you're using it to drive other build systems, rather than as a build system itself. W…
If you think Python 3 is a better tool than a Makefile you're entirely missing out on what makes "make" a useful tool. The entire point is that it's not a general-purpose programming language, so that you're forced to separate the DAG aspect of your build process from any complex logic. Sure, some things you can't do in a Makefile, and you generally shouldn't try. The Makefile should call some Python / Perl / whateve…
Re: Using Makefile(s) for Go
#63Earlier quoted context omitted.
Why do people on this website use "make(1)" instead of "make" in writing? And I know it's in the man pages but what is this number even for?
The number is the "section" of the manual: https://www.kernel.org/doc/man-pages/ My guess is make(1) is to distinguish from make(1p) - http://man7.org/linux/man-pages/man1/make.1p.html
Or just reflexively included just in case, because of commonly encountering potentially ambiguous situations that you just disambiguate by default, even for non-ambiguous situations.
Re: Using Makefile(s) for Go
#64I've seen a lot of developers, especially developers with C backgrounds, reach for Makefiles when approaching Go development, and I think it's a harmful practice. So, I'd like to offer a respectful but firm rebuttal to this article. :) I dislike using make(1) with Go for two reasons. The first is that make was developed for building C projects, and therefore is oriented around that task. Building C projects is a lot…
Why do people on this website use "make(1)" instead of "make" in writing? And I know it's in the man pages but what is this number even for?
Re: Using Makefile(s) for Go
#65I use Makefiles for Go projects all the time, but not in the way the article describes. First off, in a pre `go mod` world, if you had dependencies to check before running the build, then a Makefile was the easiest way to manage that. But even in a post `go mod` world, there are good reasons to use one that the article totally overlooks: * Makefiles introduce a topological sort to build steps. This is the reason you…
This is indeed true way beyond Go. Alternatives/replacements to make (rake, scons, bespoke shell scripts, whatever) make this in a range going from painfully non obvious to downright impossible.
For all its limitations and reputation for complexity, Makefiles can achieve a form of simplicity that renders this very simple, outrageously self documenting, and language independent.
Re: Using Makefile(s) for Go
#66It's really frustrating seeing so many Makefiles that don't _make_ anything. Make syntax is really odd. I see so many folks go out of their way to deal w/quirks of make when they really just need a shell script. You can see this anti-pattern very quickly when you see `.PHONY` targets for everything. I think make is useful for some aspects of go. GOPATH is becoming less relevant now, but still helpful when you want to…
> Make syntax is really odd
I don't find it particularly strange, except my biggest peeve - the insistence on tabs!
Re: Using Makefile(s) for Go
#67I use Makefiles for Go projects all the time, but not in the way the article describes. First off, in a pre `go mod` world, if you had dependencies to check before running the build, then a Makefile was the easiest way to manage that. But even in a post `go mod` world, there are good reasons to use one that the article totally overlooks: * Makefiles introduce a topological sort to build steps. This is the reason you…
Although, I work in a team where a lot of devs are on Windows, and they complain about it.
Re: Using Makefile(s) for Go
#68Earlier quoted context omitted.
That was an excellent comment! I use make for almost all my projects (regardless of language) and I have a system where "make init" sets up the environment (install packages, set up containers, and so on) and "make run" runs it and "make test" tests it. Now I can come back to projects from 5-10 years ago and get them running with minimal effort since all the magic is in the makefile and not my in forgetful brain.
Do you have a tutorial or book you'd recommend for how to pursue this kind of workflow? I'm definitely interested as I dabble in more languages and am beginning to struggle with some of these kinds of environmental details
Re: Using Makefile(s) for Go
#69I use Makefiles for Go projects all the time, but not in the way the article describes. First off, in a pre `go mod` world, if you had dependencies to check before running the build, then a Makefile was the easiest way to manage that. But even in a post `go mod` world, there are good reasons to use one that the article totally overlooks: * Makefiles introduce a topological sort to build steps. This is the reason you…
Also - Make will exist pretty much in any Unix-based environment. Any alternatives will require prerequisite installation of things. Although, I work in a team where a lot of devs are on Windows, and they complain about it.
Re: Using Makefile(s) for Go
#70I use Makefiles for Go projects all the time, but not in the way the article describes. First off, in a pre `go mod` world, if you had dependencies to check before running the build, then a Makefile was the easiest way to manage that. But even in a post `go mod` world, there are good reasons to use one that the article totally overlooks: * Makefiles introduce a topological sort to build steps. This is the reason you…
Also - Make will exist pretty much in any Unix-based environment. Any alternatives will require prerequisite installation of things. Although, I work in a team where a lot of devs are on Windows, and they complain about it.