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/

‪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

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

@hikari I have used m4 outside of autotools to generate Makefiles and C headers. In principle, I love it. In practice, it becomes difficult to maintain my own m4 code.

@hikari kids don't use sendmail anymore!

@hikari i mean all the projects ive touched that use python for build scripts seem just as inscrutable as autotools except somehow even more fragile

@hikari agree ... even if your build system only has to deal with a single platform, because it builds the platform, it's still hell ... it's just all awful ...

one day I'll gonna write my own build system x.x

@littlefox @hikari there are reasons i prefer build systems (for projects complex enough to need them) declarative and not turing-complete, and why i’m shilling meson so hard

(okay mostly i’m just a distro packager who also used to cross-compile for windows and… i’ve seen things)

@mia @littlefox the best build system i've ever used was declarative and turing-complete, but i can't talk about it… i should try meson

@littlefox @hikari almost every time i ran into portability issues or wrong assumptions about some platform, it was solely the build system’s fault. the code itself was usually portable enough.

if a build system makes devs deal with platform abstractions themselves, it’s not a cross-platform build system. it’s not even a “linux” build system, assuming the dev uses some linux distro. it only works reliably on the dev’s machine.

@littlefox @hikari which means that e.g. cmake is one of the worst possible choices

@mia @hikari hm, I beg to differ - well-written CMake does not really contain nasty platform stuff, if any at all

All the dependency resolution is either done via cmake-included Find$Dependency modules or, as automated fallback, stuff like pkgconfig and specifying unfound dependencies yourself is also possible by default (though it could be nicer).

I would be curious though, what kinda problems you see/saw here

@littlefox @hikari
Find modules are often broken (e.g. finding the dependency but not picking up libraries that need to be linked), honestly the whole idea of cmake having its own mechanism is bad
* pkg-config support is poorly implemented (and discouraged)
* you can’t generate .pc files from cmake especially if you’re shipping static libraries because the information you need to do that correctly is not accessible
* almost no one uses GNUInstallDirs, lots of hardcoded paths
* dependencies tied to user-facing options cannot be implemented reliably and in a fail-early manner
* cache invalidation is unreliable

just some examples of practical problems i ran into with cmake. i haven’t used it often and try to avoid packaging projects using it.

@mia @hikari hmhm, I'll keep an eye open for those - I mostly use it for my own OS and many things don't apply there, so not sure rn how bad it really is, but what I wrote above was from experiences in the past where things seemed at the very least okay-ish

thank you :)

@mia @hikari (and no, cmake is definitely not the correct tool for building an OS ... but it's what I knew at the time, it works well enough, nothing works really well)

@littlefox @hikari i mean tbf i used cmake to drive my windows build toolchain for mpv/mplayer2 back in the day. tons of ExternalProject scripts

it was Good Enough at the time. but i wouldn’t do it again.

@hikari I was with you until this part. Build systems need updating and maintenance like any other part of the product, and so if you don’t keep them at least somewhat organized it becomes a haunted graveyard.

@jrose i mean i don't think they should be neglected, but rather i am observing they almost always are