71–80 of 104 posts
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…
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
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
1. I don't like multiple makefiles. Icky with lots of duplication and high maintenance. Bad article.
2. When possible I use target expansion to generate targets in the main makefile:
APPS:= app1 app2 app3
$(APPS:%=build.%)
3. I prefer to use makefile functions rather than reaching for "bash" where possible: https://www.gnu.org/software/make/manual/html_node/Functions...
4. If something is really complicated - extract to bash
Make has been written in 10K languages and the original is still the best
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…
>A Go project should only require the Go compiler to build successfully. But they don't. The go compiler doesn't support yarn, npm, protobuf, open-api generators, doc generators like md2man, go-bindata-assetfs, gox and everything you need to complete the code generation done in modern Go applications. So how do you orchestrate this? People use Makefiles, bash scripts, go scripts and everything in between and combined…
Something like Bazel theoretically solves this problem, but it's poorly documented and non-trivial to use or operate. Other Bazel/Blaze derivatives are worse with respect to usage/operation/correctness. Nix improves on correctness but is even harder to use/operate. There's a lot of room for improvement in this space.
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.
Earlier quoted context omitted.
"For code generation and other ancillary tasks, Go includes the 'go generate' facility. This feature was created specifically to free developers from depending on external build tools. ( https://blog.golang.org/generate)" Please please please don't use go generate! While I respect your position, go generate is the worst and I hope they eventually deprecate it in future go versions. We tried go generate in some of our…
Go build constraints (build tags) also go in the comments and I think it works well enough. The arguments against are similar to those against struct tags. Without a properly defined pragma paradigm in Go comments at the top of a file work Well Enough™ IMO. I've also never seen anyone call out to protoc from a go generate flag. Sure, you can do that but it hasn't been common in the Go shops I've worked at. > You can'…
If I want to know whether a file is built, looking inside is a reasonable thing. If I want to know where generated code comes from, where do I look? How do I know?
Earlier quoted context omitted.
None of those reasons explain why a Makefile is any better than a scripting language.
Here's 3 reasons: - Makefiles are a de-facto standard. People know them and those who don't can read how they work in 2000 tutorials. They shouldn't have to read your (and everybody's) custom (and different) script to build a project they've downloaded. - Makefiles are specialised to the tasks of building, running tests, etc. A scripting language is general purpose. As such, it encourages adding all kinds of crap, fr…