social.noyu.me

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!‬

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

@hikari I have this exact thought several times a week

@hikari Is powershell good enough?

@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]”)

@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

@r @hikari oh yeah, dkP's makefiles... I remember those (vaguely, but they were a bit Fancy)

@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)

@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!)

@SoniEx2 @hikari I dunno, the only thing worse than “everything is crammed into strings” is “this binary data is structured, but still requires a schema”

@jrose @hikari hmm

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

@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. =^-^=

@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

@hikari what strikes me every time with software projects that use cmake is how messy and unstructured the build system files are. everyone does it a little differently, and there’s near-infinite potential for oversights.

how little effort is usually put into cleanliness is proof that cmake is user-hostile by design.