Iwasawa 🌟 (one hikari of too many)i don't love the tone of this article but i agree with a lot of what it says about gnu automake. my experience with it in php was awful. it belongs in the dustbin of history https://felipec.wordpress.com/2024/04/04/xz-backdoor-and-autotools-insanity/
shell scripts are arcane enough when they're little things written in bash. automake is a massive shell script library written in m4
the thing about build scripts is that nobody cares about them. you write your project in c, c++, rust, whatever… some language you know well and enjoy using. but in order to actually configure/compile/link/package it, inevitably you need Some Other Language to help you
you don't care about the beauty of your build system. build systems are hell. you just want it to work. almost always the resulting code is far from beautiful. if it is readable and well-structured, it probably hasn't made contact with multiple platforms or configurations yet
so, build scripts are the kind of unloved, neglected code where bugs too easily hide. but i think we collectively make this worse for ourselves by writing this code in unloved languages we don't or can't fully understand. python is just about acceptable. but bash? that's arcane.
m4? that's on another level. yes, of course you should learn the language if you're going to use something that requires it. but automake is basically the only reason you'd ever have to learn m4. do you care enough to bother? i doubt it! i certainly don't!
this may be unpopular, but cmake's configuration language is also arcane in my opinion. my experience with reading its documentation trying to figure out what code does and how to do anything vaguely complex with it is only pain. but that's an aside. it's okay for simple projects
anyway:
• unloved code is bad
• unloved code in arcane languages is worse
therefore:
• gnu autotools must die
• please stop writing shell scripts
• we need better build systems
btw i don't really agree with the blog post that makefiles are better. i mean, a simple hand-written makefile is definitely better than endless lines of autogenerated shell scripts that in turn generate a very complex makefile, but i don't think they scale well
gods, the world really needs a better shell scripting language
unfortunately since posting this thread i have been consumed by thoughts of what my own replacement for shell scripts would look like… am i finally going to become a real programming language designer
demize
Zack Weinberg
Annette@hikari I'm not sure what it would take to get there. There's lots of popular interactive shells that are better than bash... but it's not enough to be better. I dunno. I guess we need some lucky shell with a killer application. Like, one that happens to get some big ecosystem (like in the way Kubernetes is an ecosystem) built around it.
@nettles @hikari yeah uh I've been thinking about this a lot lately for reasons that will be obvious if you look at my posting history and
if I wrote down a list of my least favorite five programming languages, four of them would be shell languages and the other one would be Tcl
I'm not sure *anyone* knows how to design a *good* shell language
... but please try! we genuinely do know more about programming language ergonomics today than we did 40 years ago, that's gotta help, right?
agatha 
@hikari *completely misses the point and post that one xkcd about standards*
cheqampi@hikari Is powershell good enough?
Ricardo Luís@hikari TCC supports running code from a shebang, so you can technically use C99 as a scripting language 🤣
Jernej Simončič �@hikari Powershell? /s
@hikari yeah and that’s why cmake and meson exist
cmake is, by all accounts, hell. I’ve used meson a little and it’s pretty nice but also has the Apple problem a little bit (“it just works [but only when you don’t need anything out of it it wasn’t specifically intended for]”)
R@hikari for C projects we used to use hand-written makefiles derived from a blend of devkitPro's makefile system combined with knowledge we had picked up from the O'Reilly gnu make book, and it just worked. nowadays we tend to use either Rust or we get really jaded and use the "fuck it" build system of a "build.sh" containing just build commands without any dependency tracking
🗦new🗧 FireFly
Jordan@hikari Unfortunately, no one has made a better DSL for
spawn than shell. Perl and Ruby are closest, but Ruby conventions have moved away from being spawn-friendly, and Perl isn’t much better than shell in terms of maintainability for most people.@jrose yeah i was going to say, the world desperately needs a better shell scripting language
@hikari “but they have! check out nushell or fish! or that other one!” you want me to learn another language and put it in my repository? making it a build dependency? yeah right
(which is why the best answer so far is “make your package manager do it”, but that’s definitely only an 80/20 solution)
Genders: ♾️, 🟪⬛🟩; Soni L.@jrose @hikari you can make shell unusable with the help of protobuf main,
(protobuf shell was supposed to integrate with protobuf main to make it more usable, but we never made a protobuf shell. we did, however, make exactly one executable that uses the protobuf main calling convention over regular linux spawn, because shoving raw binary data into argv was too exciting to pass up!)
well, we never figured out how to shove the schema into the binary... but what's wrong with requiring a schema?
it's more efficient or something.
https://github.com/SoniEx2/protobuf-main
more excitingly, a schema can be translated (e.g. between english and portuguese) without affecting the format.
@SoniEx2 @hikari I mean, it’s no different than shoving binary data over stdin/stdout, but still. Having a schema means that things go wrong in weird ways when two programs don’t agree on the schema. And at least when that happens with text or with something purely structural, you can point to where the unexpected thing was.
@jrose @hikari ah, yeah... protobuf is particularly suited to this due to its strong backwards and forwards compatibility design, further we can embed the schema into the binary so you can compare the one in the binary with the one in the protobuf shell script and whatnot. which should help, we think.
protobuf main still allows you to redirect stdin tho. =^-^=
Saphira Lohikäärmekettunen 
@hikari "not all shell scripts are bad!!11"
... but besides that, I fully agree - and I'll think about shell scripts ^^'
@hikari also .. look at what you did /o\
https://gotosocial-dev.svc.0x0a.network/@littlefox/statuses/01HTR9V6WYC3FTXGPJ0DB25WFF
Post by lohikäärmekettu kernel crashdev , @[email protected]
Hmm ... applying the Golang package system to C and C++ in a build system? Like, you just compile all C and C++ sources in each directory into a static library, which you then link together with whatever depends on them. Each directory has a meta file stating "imports", which are just which ...
poetaster@hikari cmake really does suck. Autotools too. Make is a self consuming shell hack hell. But, in the end, a good build system is probably still a shell hack. I dunno, i use a lot of build tools. I edit all the foo with vim in the end :-)
I do find that taking cmake graphs down the rabbit hole apart can be instructive. even if the result is that I rip it all appart and just use header file includes as if I was shopping at tiffany's. I alwas feel happy when I can just run gcc . And then there's the go ecosystem :-)