Live data from Hacker News

Using Makefile(s) for Go

danishpraka.sh

61–70 of 104 posts

Re: Using Makefile(s) for Go

#61
post #17
post #3

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?

They're showing off their geek creds. "I know what man page sections are" essentially. There's absolutely no practical reason to use it in a comment.

Re: Using Makefile(s) for Go

#62
post #26
post #6

Earlier 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…

Read the last paragraph of my comment. I am entirely aware of what Make does.

Re: Using Makefile(s) for Go

#63
post #18
post #17

Earlier 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

> 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

#64
post #17
post #3

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?

Unlike “ls” and “cp”, “make” is a real word, so to help us human readers parse the document’s prose, adding the section number in parentheses gives our brains a quick clue as to what’s going on.

Re: Using Makefile(s) for Go

#65

I 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 the reason you use it instead of build shell scripts: it allows build steps to run in parallel, it guarantees order by dependency which is the best way to read build steps, and it makes file freshness an easy element to check for a build step

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

#66

It'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…

Is there a way to easily have something like make targets in a shell script, without a ton of boilerplate?

> 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

#67

I 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

#68

Earlier 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

Managing Projects with GNU Make by O'Reilly is a good start. Make is much less mystifying if you get through all of its quirks. Make is not great in many ways (significant tabs are annoying, for example), but it's no SBT.

Re: Using Makefile(s) for Go

#69
post #67

I 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.

What do Windows devs prefer instead of Make?

Re: Using Makefile(s) for Go

#70
post #67

I 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.

I'm pretty sure MacOS and most of the headless Linux distributions require you to install it (from a package manager or similar). It's not hard, but usually the alternatives aren't hard to install either.
Post reply on HN