Earlier quoted context omitted.
Not downvoting you. Just curious to know why? In my experience, as long as the Makefile is less than about 100 lines, it's the most useful workflow system ever. Because it's available almost everywhere. After about 100 lines, yeah, it is not great. And that idiotic tab character. I know the historical reason why tab was used. I wish they had fixed it to accept both tabs and spaces a long time ago.
You see, this is why I personally hate make: automake. As you say, a small elegant makefile is lovey. That is not the sort of makefile you get from the autoconf/automake family, and (ha!), good luck if something goes wrong. The reality is that a small simple makefile is not sufficient to build real software. The problem is fundamentally that make doesn’t compose well. Most real build systems such as cmake, scons, car…
Using Make – writing less Makefile
131–140 of 200 posts
Re: Using Make – writing less Makefile
#132Nice to see some love for make. Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great). But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well. I'd go so far as to say…
> But make is widespread, ancient and eternal. Yeah. The GNU Make is literally everywhere, it's too useful and it's got too many good features. GNU Make is worth learning and using just because of this. Having to deal with non-make systems is seriously annoying. > It does many jobs relatively well. I wonder if anyone else other than me was insane enough to try and use GNU Make to manage dotfiles? I even blogged about…
> I wonder if anyone else other than me was insane enough to try and use GNU Make to manage dotfiles?
Not a bad idea IMHO… thanks for the blog post. I'm tempted to try something similar.
Re: Using Make – writing less Makefile
#133Re: Using Make – writing less Makefile
#134Is there any reason to use make over ninja and gn?
This is why I wrote https://bernsteinbear.com/blog/ninja-is-enough/ :)
Re: Using Make – writing less Makefile
#135I say this as someone with 20+ years of experience in C and C++: Using make is a huge waste of time in 2023 (and forward). Learning the intricacies of make actively blocks you from Getting Things Done. Yeah, make is kind of neat because it has this functional what_I_want : how_to_get_it syntax, but it doesn't actually work that way. It's a huge waste of time to try to get it working so unless you meet the following c…
"Make actively blocks you from Getting Things Done."
--Quote from someone suggesting CMake.
Re: Using Make – writing less Makefile
#136Earlier quoted context omitted.
Not downvoting you. Just curious to know why? In my experience, as long as the Makefile is less than about 100 lines, it's the most useful workflow system ever. Because it's available almost everywhere. After about 100 lines, yeah, it is not great. And that idiotic tab character. I know the historical reason why tab was used. I wish they had fixed it to accept both tabs and spaces a long time ago.
> I wish they had fixed it to accept both tabs and spaces a long time ago. I have good news for you: this is already the case! In all modern versions of make you can use semicolons instead of tabs. You just write target : dependencies ; rule instead of target : dependencies ^Irule if, for some reason, you hate the beautiful tab characters.
Ha, what if the 'rule' is 5 lines long?
Many times, a Makefile snippet in an HTML page or a PDF file has had the tab character auto-magically morphed into spaces. So when it is copied, it will be a syntax error in a Makefile. Even copying Makefile snippets from one terminal window to another will eat those tab characters. Fortunately my vim editor is configured to handle most of those edge cases now, but it took me... I don't know... 10-15 years to get that right.
My personal rule is that control characters which are visually indistinguishable from other characters have no place in source code which are meant to be written, read, and copied by human beings. So yeah, that includes the character. And yes, I do think the Golang people got that wrong, although the 'go fmt' command largely solves that problem. Except when reading Go source code on web sites which don't handle tabs well, and you are nested 6 levels deep, and half the code is unreadable because it's bled off the right side of the page.
Re: Using Make – writing less Makefile
#137Earlier quoted context omitted.
> But make is widespread, ancient and eternal. Yeah. The GNU Make is literally everywhere, it's too useful and it's got too many good features. GNU Make is worth learning and using just because of this. Having to deal with non-make systems is seriously annoying. > It does many jobs relatively well. I wonder if anyone else other than me was insane enough to try and use GNU Make to manage dotfiles? I even blogged about…
> I wonder if anyone else other than me was insane enough to try and use GNU Make to manage dotfiles? Not a bad idea IMHO… thanks for the blog post. I'm tempted to try something similar.
The real makefile that I use and wrote about has some features that I didn't get around to describing in the blog post. Also has a ton of comments.
https://github.com/matheusmoreira/.files/blob/master/GNUmake...
The metaprogramming template I described is used to implement XDG Base Directories. The links take the XDG variables into account while the real files live in their default locations inside the repository.
Re: Using Make – writing less Makefile
#138Quasi-tangent: I was once hit by a coworker doing first code review on a new repo with "hmm...I'm not familiar with using Makefiles as a project management tool. So something something [don't remember] we should replace that." It struck me as weird because I don't see `make` as a build tool so much as automating shell script snippets you would/could type at the command line. From that POV I conceptually see Makefiles…
I really like GNU Make because it has a hidden superpower: the "-j" parameter enables instant, easy parallelization. I have a project with many subprojects and I use "-j16" to invoke the same command in all of the subprojects, 16 at a time. It saves a lot of time and it works for all commands that don't touch other subprojects. Like you, I use Make as a front end to lower level build tools. It seems to fit that role…
I think this is a great example of tools being stuck in the 90's, actually. Make should be parallel by default.
I get it, I do. I know there's all sorts of legacy reasons, but my 4k resolution screen with 12GB vram and 32 cores still runs make build serially, outpitx to an 80x24 window and is bottlenecked down by stdout flushing, all because we can't change defaults.
Re: Using Make – writing less Makefile
#139Earlier quoted context omitted.
You see, this is why I personally hate make: automake. As you say, a small elegant makefile is lovey. That is not the sort of makefile you get from the autoconf/automake family, and (ha!), good luck if something goes wrong. The reality is that a small simple makefile is not sufficient to build real software. The problem is fundamentally that make doesn’t compose well. Most real build systems such as cmake, scons, car…
http://9p.io/sources/plan9/sys/src/mkfile
Woah, what is that @{ construct in that mkfile? I cannot find it in the GNU Make Manual (https://www.gnu.org/software/make/manual/make.html). I use backslash-before-newline for multi-line loops like that.
Re: Using Make – writing less Makefile
#140Earlier quoted context omitted.
I really like GNU Make because it has a hidden superpower: the "-j" parameter enables instant, easy parallelization. I have a project with many subprojects and I use "-j16" to invoke the same command in all of the subprojects, 16 at a time. It saves a lot of time and it works for all commands that don't touch other subprojects. Like you, I use Make as a front end to lower level build tools. It seems to fit that role…
I think this is a great example of tools being stuck in the 90's, actually. Make should be parallel by default. I get it, I do. I know there's all sorts of legacy reasons, but my 4k resolution screen with 12GB vram and 32 cores still runs make build serially, outpitx to an 80x24 window and is bottlenecked down by stdout flushing, all because we can't change defaults.
And annoyingly, I don’t think there’s a way to tell `make` that a particular `Makefile` should be built with multiple threads by default. So you have to specify `-j` every time.