4 ms·
Reads a lot like Stockholm Syndrome. Make is terrible. It's just widespread, not very hard to start with and better than all the alternatives (which often are
by sph 4y ago
Reads a lot like Stockholm Syndrome.
Make is terrible. It's just widespread, not very hard to start with and better than all the alternatives (which often are better, but not as easily found or preinstalled)
But it is obtuse for no good reason other than being a piece of software born in a long-gone era of computing. Whoever loves Makefile has never had to debug the compilation process of any non-trivial build system, with three dozen ways to define variables, rules and targets, spread over multiple files.
When in doubt, I'll create a Makefile (actually, I use `just` for my personal projects because 99% of the time in 2023 one just needs a task runner). There is much better software to write love letters about.
- blueflow 4y agoI don't understand what you are unhappy about. When maintaining recipes for building packages, i'd always prefer to debug a Makefile where i can insert a `sh -x` than some magic tools that attempts to do everything for me and then fails without observable reason.
- duped 4y ago> than some magic tools that attempts to do everything for me and then fails without observable reason. Ok, but then what about autoconf/autoreconf, aclocal, and automake used to generate makefiles for what seems like the entire GNU ecosystem? At least the "magic" tools that are more modern have documentation. You can print debug a cmake build pretty dang easily, and it at least doesn't pull in the entire user environment implicitly.
- blueflow 4y agoPlease back up the implicit claim of missing documentation.
- JohnFen 4y ago> Ok, but then what about autoconf/autoreconf, aclocal, and automake used to generate makefiles for what seems like the entire GNU ecosystem? I thought we were talking about make, though. Autoconf and the ilk is an entirely different conversation.
- deleted 4y ago[deleted]
- JohnFen 4y ago> Whoever loves Makefile has never had to debug the compilation process of any non-trivial build system, with three dozen ways to define variables, rules and targets, spread over multiple files. I dunno. I've done that many times over the years, and I still love make. It certainly has its flaws, but it also has benefits. For me, the cost/benefit of make is better than any other such system that I've tried.
- pydry 4y agoI find a bash script with one big case statement and a hard limit on file length is pretty underrated.
- mananaysiempre 4y agoEven if you’re always rebuilding everything, where makefiles win over a flat script is being able to group things, e.g. CFLAGS = -g -O2 all: foo foo: ; # how to build foo install: install-foo install-foo: ; # how to install foo clean: clean-foo clean-foo: ; # how to clean foo all: bar # etc. This is somewhat similar to AWK’s “pattern-action” structure and perhaps literate programming, but otherwise I struggle to describe how it fits into the world of programming languages. The ability to override variables from the command line is also pretty sweet: e.g. with the above you can get a non-optimized build with `make CFLAGS=-O0 clean all`. But I guess by using ${CFLAGS=...} you could get `CFLAGS=-O0 ./build.sh` to work as well.
- xdennis 4y agoPersonally I use this pattern to make subcommands: main() { if [[ $1 ]]; then cmd_"$@" return fi cmd_all "$@" } cmd_all() { cmd_something "$@" cmd_some-other-thing } cmd_something() { ... } cmd_some-other-thing() { ... } main "$@" I find it much easier to understand when you execute things in a predictable order and you can have a `set -x` to follow everything through. If it's too slow, then only the show bits should be parallelized. At work, on the other hand, every project uses something like this in the Makefile: -include $(shell 'pwd')/makefile-modules/*/*Makefile* That, and wildcard job names makes it quite difficult to follow the flow when things break.
- tipiirai 4y agoObviously not terrible for everyone. There are clouds of people who like it, even love it.
- gpderetta 4y agoI'll prefer debugging Makefiles any day than cmake. But I yield to the de-facto standard.
- Izkata 4y ago> > compilation process of any non-trivial build system I kinda get the feeling they're mainly complaining about autogenerated Makefiles from the output of cmake and similar...
- JohnFen 4y agoOOhhhh! If that's the case, then I'll join the chorus complaining about it. Autogenerated makefiles tend to be nasty.
- sph 4y agoI've recently had to debug LLVM cmake on Windows, with a good dose of .bat scripting. That was truly hell on Earth.
- oneeyedpigeon 4y ago> Whoever loves Makefile has never had to debug the compilation process of any non-trivial build system Whoever hates Makefile has never been forced to use ant.
- sfpotter 4y agoAgreed. I personally reach for Makefiles in exactly one situation: in research, when I’d like to collect lots of results from many computational experiments to make some plots or tables. I might have the whole process of re-running the experiments and rebuilding the final manuscript driven by Make. But even for this task, it feels pretty awkward and painful. I did try using Scons for the same purpose but didn’t like it as much.
- m000 4y agoWho said anything about compilation? Compilation is the use-case that helped make to gain traction. Make has long become outdated for the specific use-case, but it otherwise remains a fantastic general-purpose automation tool.
- inetknght 4y ago> but it otherwise remains a fantastic general-purpose automation tool. ...can you recommend a static analyzer and linter for Makefiles?
- blueflow 4y ago`make`. Like half of all its options are for tracing, debugging and outputting internal information.
- sph 4y ago> fantastic general-purpose automation tool It is not though. It's a barely passable automation tool that's just slightly better than bash as a tool runner.
- lynx23 4y agoHey killjoy, your reply reads a lot like the conservative father of a love-smitten youngster.