Live data from Hacker News

Using Makefile(s) for Go

danishpraka.sh

11–20 of 104 posts

Re: Using Makefile(s) for Go

#11
This... isn't even using the `make` part of Makefiles at all.

If you look at the final example, every [1] rule is marked as `.PHONY`. `make` bundles 2 capabilities: a dependency graph and an out-of-date check to rebuild files. This demonstration uses neither.

The author would be better served with a shell script and a `case` block. The advantages:

- Functions! The `check-environment` rule is really a function call in disguise.

- No 2 phase execution. The author talks about using variables like `APP`, but those are make variables with very different semantics than shell variables (which are also available inside the recipes).

[1] Yes, there's a `check-environment` "rule" that isn't marked, but it likely should be since it isn't building a file target named `check-environment`.

Re: Using Makefile(s) for Go

#12
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 have build-time dependencies in $PATH

    $(GOPATH)/bin/some-dependency:
        go get -u ...
I still use make when building artifacts, especially in CI. But as a default, I almost always try to talk folks out of using make for this sort of stuff.

Re: Using Makefile(s) for Go

#13
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…

I avoid using makefiles, unless I need them :). Yes, plain Go projects which are supposed to produce an executable probably won't need a makefile and I haven't used any for those. But if your project should produce a shared library, it is nice to wrap the build command in a makefile, as it is easier to type "make".

Also, when integrating into larger projects or when other tasks in addition to building the Go project are required, unifying them with makefiles can be helpful.

Re: Using Makefile(s) for Go

#14
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…

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

Re: Using Makefile(s) for Go

#15
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…

I agree if you end up using Make like its used in C projects: compiling intermediate objects, linking them, etc. In that case the Go compiler should suffice.

I almost exclusively use Make for projects in any language nowadays as workflow automation, this includes Go, Python, Terraform, Docker builds.

In this way Make is a indispensable tool for me. As for me it's portable where it matters (macOS, Linux, WSL), it's ubiquitous, it has a stable API and it's behaviour is well know to me. Sometimes I have to work around some shortcomings of Make, eg: things that don't produce a file as result, where you `touch` a fake artifact file. But this is a minor annoyance for me compared to what Make brings in term of how simple and declarative I can automate my workflows.

Re: Using Makefile(s) for Go

#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?

Re: Using Makefile(s) for Go

#18
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?

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

Re: Using Makefile(s) for Go

#19
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…

It's not just Go, loads of projects use Makefiles as a collection of Bash scripts. I've never really been certain what it actually buys you...

Re: Using Makefile(s) for Go

#20
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…

As soon as you have a semi-complex project makefiles or some other custom scripts are required. Go tools alone won't do. There is this attitude that sees Go as the center of the universe, it is not. If people say idiomatic, it makes me laugh.
Post reply on HN