Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I stopped worrying and loved Makefiles

gagor.pro

Post reply on HN
Print view View original

81–90 of 144 posts

Re: How I stopped worrying and loved Makefiles

#81

Post by dissent »

One issue I don't hear mentioned often is reuse.

A task runner's tasks could be arbitrarily complicated, pulling in all sorts of dependencies of their own. This is less true for the traditional compile targets make was designed for.

Because the things we do in a Makefile are pretty much always project local and don't get reused, it limits how much heavy lifting these tasks are likely to do for us. Whereas if you built your our CLI in Python with Click or something, you would be able to make it a development dependency of your project. You can afford to invest in those tasks more because they'll be reused.

The Just command runner has the same problem, but at least it's designed to be a task runner.

Re: How I stopped worrying and loved Makefiles

#82

Post by ricardobeat »

frankwiles wrote: post #14

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.

Came here to say the same. Make works fine, until it evolves into a web of commands and associated shell scripts, and then most users give up on trying to understand what is happening. Justfiles are much more manageable.

Re: How I stopped worrying and loved Makefiles

#83

Post by JonChesterfield »

defrost wrote: post #70
JonChesterfield wrote: post #69

Earlier quoted context omitted.

Sed confuses me more than awk but you're right. That would also remove the only use of awk in my makefile (sed is there already for hacking around spaces in filenames). Whitespace padding output in sed is probably horrible, column looks simpler than printf via bash or trying to use make's $info.

Whilst acknowledging that "Confused by SED" has overlap with "have used SED for 40 years and have three books purely on SED" I can recommend https://www.grymoire.com/Unix/Sed.html as a reference some might occasionally swear by. Anyhow, sed is a marvelous utility. Unfortunately, most people never learn its real power. The language is very simple, but the documentation is terrible. The Solaris on-line manual pages for…

Appreciated, reading through it. I suspect the majority of the sed experience can be attributed to it using "posix regular expressions" by default. It was about a decade after first discovering sed that I realised passing -E was really important.

It is difficult for newcomers to guess that "extended regular expressions" refers to the barely-usable subset of "regular expressions" and "posix regular expressions" are terrible in comparison to either.

edit: alright, yes, one can program in that. Sed can recurse.

  .PHONY: help3
  help3:
   sed -nE 's/^([a-zA-Z_*.-]+):.*## (.*)$$/\1 :\2/ p' \
   $(MAKEFILE_LIST) | \
   sed -E -e ':again s/^([^:]{1,16})[:]([^:]+)$$/\1 :\2/ ' -e 't again '  |\
   sed -E 's/^([^ ]*)([ ]*):(.*)$$/\1:\2\3/' |\
   sort
The first invocation filters out the lines of interest, second one space pads to 16. That works by putting the colon before the help text and repeatedly inserting a space before the colon until there are at least sixteen non-colon characters in the first group.

Composing the -n/p combination with act on everything is a stumbling block for merging the multiple invocations together but I expect it to be solvable.

Re: How I stopped worrying and loved Makefiles

#84

Post by alextingle »

akdor1154 wrote: post #27

I'd love some minor tweak of Make to compare/cache with hashes instead of mtime. A worse-is-better Bazel if you will.

This is better achieved with the compiler level tooling, rather than in Make. It's pretty easy to replace `cc` with a short script that runs the pre-compiler and compares the result with a cache.

If the source code is kept tight, it doesn't yield much of a speed-up, though - precompiling hundreds of unnecessary headers can take a lot of time. Better to put some effort into moving unnecessary #includes out of header files. In fact, you can use your log of cache-hits to guide that work.

Re: How I stopped worrying and loved Makefiles

#85

Post by alextingle »

TheRealPomax wrote: post #43

The fact that make is basically useless on Windows still makes it "not the first thing to try", to be honest. And it's rare to still see a project that can't be cross-platform, only lots that went "well my computer runs XYZ so I'm only compiling on that" =)

Make works just fine on Windows.

Re: How I stopped worrying and loved Makefiles

#86

Post by lelanthran »

tomjen3 wrote: post #52
ReleaseCandidat wrote: post #38

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…

> 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

With maybe one (or two) exceptions, those other languages' build systems are incredibly susceptible to supply-chain attacks.

And, to be honest, unless you have a burning need for autoconf's main value proposition (cross-compiling for a different target system), plain gnu-make and storing your dependencies in your repo is probably a lot safer than many other build systems.

I've built software with dependencies on libpng, libcurl, libsodium and more and was confident in the security of the resulting binary. I've also done one or two node.js projects, and had much less confidence that it won't be supply-chain attacked on the next build.

Re: How I stopped worrying and loved Makefiles

#88

Post by lelanthran »

jaza wrote: post #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 o…

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

Make has its warts (look at when and what it was designed for, after all!), but I've found it much easier to write Makefiles than YAML-for-github-runners.

If you're used to YAML, you get pleasantly surprised when using Make, which does execution of dependency trees in a more readable manner than most CI/CD YAML files do.

Re: How I stopped worrying and loved Makefiles

#90

Post by lelanthran »

wizhi wrote: post #79
blipvert wrote: post #54

Earlier quoted context omitted.

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.

> But this can literally just be done in a simple shell script as well.

Only if there's no dependencies. It's unusual that GP's type of usage has no dependencies.

Post reply on HN