Live data from Hacker News

How I stopped worrying and loved Makefiles

gagor.pro

71–80 of 144 posts

Re: How I stopped worrying and loved Makefiles

#71
post #52

Earlier quoted context omitted.

You do know that there is software that runs on more than one version of Linux (or even on a *BSD, MacOS or Windows), works with more than a single version of a compiler,...?

Thats only really a problem for C/C++, which I have had the misfortune to make build systems for. The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far and until we do this, ship the dependencies with the program. And if you aren't making a GUI and don't need to target Windows, just wrap it in Docker, which enforc…

[dead]

Re: How I stopped worrying and loved Makefiles

#72

If you’re really looking for a tool to collect small steps/script I highly recommend you check out the ‘just’ cli tool. It’s completely replaced our use of Make and the syntax is much easier.

Have moved all my 'frontend' Makefiles to Just and couldn't be happier.

Re: How I stopped worrying and loved Makefiles

#73

If you're going to use Makefiles as a top-level build wrapper you might be interested in self-documenting targets. https://marmelab.com/blog/2016/02/29/auto-documented-makefil...

The punchline here is a help target that digs through your makefiles looking for comments: help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' I stumbled over .*? since ? usually means optional, but turns out it means lazy in this context. The $$ would be makefile escaping. Dropping the grep and changing the regex slightly, I…

I have been doing this for a long while now, and it's great

Re: How I stopped worrying and loved Makefiles

#74
post #50

This pattern of usage always seems like abuse. When `make` is used as a glorified front-end to `bash` scriptlets, why not use `bash` directly instead of having two-level of scripting? See: https://blog.aloni.org/posts/bash-functional-command-relay/

Because the Makefile also becomes a central place of what you can run in a project without having dozens of different shell scripts. You can comment on targets, depend on others. Makefile targets to restore, the build i18n files, etc

I made a bash script that takes your Makefile and gives you a nice dialog menu for the targets that have comments. Works nicely as a self documenting project command menu.

https://gist.github.com/oppianmatt/dcc6f19542b080973e6164c71...

https://private-user-images.githubusercontent.com/48596/3262...

Re: How I stopped worrying and loved Makefiles

#75

What's the rationale for using makefiles as script runners over just having a directory with scripts inside? Not for compiling, just as script runner. I see this practice often and I haven't found a good reason

If scripts need particular arguments the make is a good place to record them. I use it quite a lot for automating deployments - if you want to Terraform up a VM: make colo1-fooserver01.vm Then if you want to run Ansible against it: make colo1-fooserver01 You don’t have remember or type all of the flags or arguments - just type make and hit tab for a list of the targets that you can build

Most shells will tab complete after `./scripts/` too. In fact that's probably more common than make completion.

I think the real reason is you have it all in one file rather than multiple scripts which makes it easier to edit and maintain.

Re: How I stopped worrying and loved Makefiles

#76
Thanks! That article demystified quite a bit of the magic of Makefiles for me.

However, even after 10+ years of professional dev work during which I've regularly crossed paths with Makefiles, they still scare me, and I've still never written one from scratch myself. I cling to bash scripts, which I'm also a rookie at (or, for more complex cases, I write Python scripts, which I'm much more comfortable with).

I guess one day I'll read the manual, and digest some tutorials, and actually learn make. But I've made it this far...

Re: How I stopped worrying and loved Makefiles

#77
post #50

This pattern of usage always seems like abuse. When `make` is used as a glorified front-end to `bash` scriptlets, why not use `bash` directly instead of having two-level of scripting? See: https://blog.aloni.org/posts/bash-functional-command-relay/

GNU Make gives me:

   - tab completion of targets
   - automatic dependency execution
   - automatic entry points between every task
   - result caching
   - parallel execution
Yes, it’s possible to do all of this by hand in shell scripts. But why would I, when Make is ubiquitous and battle-tested?

Re: How I stopped worrying and loved Makefiles

#78
post #50

This pattern of usage always seems like abuse. When `make` is used as a glorified front-end to `bash` scriptlets, why not use `bash` directly instead of having two-level of scripting? See: https://blog.aloni.org/posts/bash-functional-command-relay/

`make` does dependency resolution. That's its original job, by the way, and calling out the dependency resolution steps to bash was the original intention.

Re: How I stopped worrying and loved Makefiles

#79

What's the rationale for using makefiles as script runners over just having a directory with scripts inside? Not for compiling, just as script runner. I see this practice often and I haven't found a good reason

If scripts need particular arguments the make is a good place to record them. I use it quite a lot for automating deployments - if you want to Terraform up a VM: make colo1-fooserver01.vm Then if you want to run Ansible against it: make colo1-fooserver01 You don’t have remember or type all of the flags or arguments - just type make and hit tab for a list of the targets that you can build

But this can literally just be done in a simple shell script as well. The makefile ends up just being a redundant way to run a shell script.

Re: How I stopped worrying and loved Makefiles

#80
post #50

This pattern of usage always seems like abuse. When `make` is used as a glorified front-end to `bash` scriptlets, why not use `bash` directly instead of having two-level of scripting? See: https://blog.aloni.org/posts/bash-functional-command-relay/

Making sure a dependency is up to date before doing something is annoying. Building a representation of dependencies to figure out what can be done in parallel is a bit more complex. Doing it for dozens of targets is a major pain in the backside.

Sure, you can do it in bash, or python, or whatever. But then you have a cumbersome, not particularly interesting piece of code full of boiler plate. Of course, you can design it a bit, organise things neatly, and then use a config file because fiddling with the code in each project is unsustainable in the long run. At this point, you’ve just made a poor copy of make and thrown away all the good bits that result from decades of experience and weird corner cases.

The syntax of Makefiles is terrible, but make itself is very useful and versatile.

And that pattern is not abuse, it’s the sort of things Make was designed for. It’s just that we’re used to think of make as this old thing that just runs a compiler and that’s such a pain to deal with that we need Makefile generators to do it properly. And certainly that’s true for complex software compilation, but make is more versatile than that.

Post reply on HN