✧✦Catherine✦✧if you like autotools we definitely aren't going to be friends
this is because autotools gives you the sort of brain damage that makes you look at some of the most atrocious interfaces in existence and go "This is good actually. I will go and argue with strangers about how good my dogshit collection of generated shell scripts is" instead of building anything that improves people's lives rather than worsening them
anyway I hate autotools and if you try to convince me that autotools are good I will probably hate you, too
people think I like cmake because I hate autotools. nothing could be further from truth. cmake is a barely-functioning pile of atrocious C++ that includes what is probably the second-worst interface of a build system. however, my hatred for autotools far eclipses my desire to never interact with cmake again, to the point where I ended up becoming a cmake expert against my wish and desire
I would strongly prefer to never use cmake again in any context (even though it would mean I don't get to charge people quite nice consulting fees to unfuck their CMake situation), but unfortunately people keep making build systems that are inexplicably somehow worse, like Bazel
(Bazel makes a lot of sense if you are Google, and is excruciatingly painful to use if you aren't Google. it's also almost completely undocumented; if you thought it was hard to figure out how to make CMake does something, allocate like 20× as much time for Bazel)
Florian 'floe' Echtler@whitequark Reading this thread and the replies seems to indicate that a non-horrible build system cannot exist. As two additional data points, allow me to throw in Scons and Gradle. 😖
@floe I haven't had experiences with Scons (good or bad) but Gradle is like the software equivalent of a word that's followed by "I'm sorry. It's terminal" because whenever I try to use it, if I end up hitting a problem I rarely actually manage to fix it (I genuinely don't understand how people do Android development)
@whitequark Back in Ye Olden Days, I had to use Scons for a medium-scale research project in C++ and all I remember is a good deal of cursing 🤷
And Android development works just fine as long as you complete the project before the next Gradle release and never touch it again 🙄
Will@whitequark @floe Oh, you can always fix problems in Gradle! You just write a bunch of arbitrary Kotlin (and thank god for that, it used to be *Groovy*, which was much, much worse) to do absolutely anything you want in the middle of the build. (Finding the runes to run your arbitrary code *at the correct point* in the middle of the build is an eldritch task to which you should plan to sacrifice an intern a quarter, more or less.)
This causes no problems whatsoever and results in builds which are fast, stable, and easy to understand.
@whbboyd @whitequark me while reading "sacrifice an intern per quarter"
Ruud van Asseldonk@whitequark @floe GN was okay last time I used it, which admittedly was 10 years ago and also the hard parts of the build config were maintained by others, but it was nice to use.
Bruno Nicoletti@floe @whitequark There’s also jam and bjam! Many years ago I made the mistake of flipping my company’s build system to use jam. Stupid move.
@floe @whitequark And the scars of building the boost libraries with bjam ran so deep that I’ve refused to use boost on any of my own projects for years.
I can also complain about the package managers for C/C++. Conan drove me nuts trying to get things building to WASM, I discovered Cmake Package Manager which works very nicely with ccache, and I haven’t used conan since.
The one thing that could turn me into a Rust bore is cargo.
OblomovDoes Makefile plus a bunch of hand-coded scripts count as a build system?
@oblomov @whitequark This is the way. 👌
arclight@whitequark I'm not sure if you're familiar with it, but I found Professional CMake to be an essential reference https://crascit.com/professional-cmake/ It's relatively cheap ($30) and regularly updated. It doesn't make CMake better but it saved me tons of time and hair-pulling.
@arclight I'm not! somehow over the years I learned enough about CMake quote-unquote naturally that I rarely encounter such issues these days
mid_kid@whitequark Having debugged and written both cmake and autotools as a packager and a developer, I would still pick autotools.
I won't lie: the m4 macro language is offputting, the generated files litter the repo, and let's not speak of libtool.
It's just, in terms of "out of the box" correctness, it does most things right. It's also really easy to debug, the config.log is amazing, and everything is extensible with just shell and make.
Different flavors of kool-aid, really. Meson is better.
I won't lie: the m4 macro language is offputting, the generated files litter the repo, and let's not speak of libtool.
It's just, in terms of "out of the box" correctness, it does most things right. It's also really easy to debug, the config.log is amazing, and everything is extensible with just shell and make.
Different flavors of kool-aid, really. Meson is better.
@whitequark As for why not cmake: its (bad) cross compilation support is holding back the entire C ecosystem, it's less easy to work around problems with bad cmake files, and *boy* do people love to write genuinely badly behaved cmake files.
Maybe it's because of what kinds of projects use it, but I can almost never build a cmake project expecting it to be a well behaved build, and end up patching bad cmake files way too often. This applies to plain makefiles as well.
Maybe it's because of what kinds of projects use it, but I can almost never build a cmake project expecting it to be a well behaved build, and end up patching bad cmake files way too often. This applies to plain makefiles as well.
@mid_kid this is pretty much how I feel about autotools, haha
StaticRocket@whitequark bazel being hyperfucked on aarch64 native machines while shipping it's own modified Java runtime through an external manager was enough to get me to avoid all projects using it for good.
@whitequark meson and cmake are good enough. If meson could take a hard stance on pkgconf vs pkg-config then we could have perfectly fine cross compilation. Unfortunately they let you use pkg-config and then only set variables that pkgconf knows how to use.
captain notgull@whitequark You know it’s bad when the best option for building C code is a plain Makefile.
Andrew Kelley@whitequark did you try zig build yet? it's got issues (mainly lack of API stability) but at least you get to use a real programming language!
@andrewrk nope, will do! I'm incredibly happy with zig cc so this definitely motivates me to look into the other bits here
@whitequark yay! makes me happy to hear someone with fine taste say that :)
@andrewrk we shipped zig cc (via pypi) in production at chipflow and i continue to maintain the pypi bridge... unfortunately it did bump into the PyPI size limit and i couldn't get it lifted so far
btw just noticed this:
Speaking of ziglang/zig-pypi#40, pypi/support#8180 would really valuable to have, zig is an important part of the toolchain of building manylinux-compliant python packages using rust.
you're doing a great job, I think :D
robinm@whitequark Did you try meson? I have never been able to understand how to properly use cmake, but meson felt somewhat fine.
asie@whitequark ain't that the fate of every build system user summed up
do you like meson because you hate CMake and Autotools, or is there a secret third hate
do you like meson because you hate CMake and Autotools, or is there a secret third hate
@asie I keep trying to use meson every once in a while but it seems like (as of last attempt) it's still incapable of producing Wasm binaries and the developers are actively against adding the sort of hooks you'd need to add such support yourself, so I kinda don't consider it a serious contender
@whitequark ah.
yeah in those situations i just resigned to writing Makefiles by hand. maybe it's the wrong tool for the job but at least I can understand them when they break
yeah in those situations i just resigned to writing Makefiles by hand. maybe it's the wrong tool for the job but at least I can understand them when they break
Peter Bindels@asie @whitequark nah, there's the other category of build systems that don't allow you to do whatever arbitrary stuff, which don't gather many users because the users don't want the build system to tell them "this is dumb and we're not going to allow it".
Maya@whitequark My commiserations.
Having to decide between autotools and cmake is a Scylla and Charybdis situation.
Li ~ Crystal System@whitequark and then theres meson, meson is nice but then meson has an annoying thing where it wants you to do things in exactly the way they expect and if you don't do that it doesn't work; you will have all your subprojects in a folder named "subprojects" and you will like it! your projects will not interact with eachother in any way and be completley isolated and YOU WILL LIKE IT
.. :/
maybe tsoding was right with that whole nob.h thing
@Li yeah, meson has the GTK/GNOME problem of having the hubris to believe you've covered every important use case but not the humility to recognize it when you're wrong. it is offputting to me on an interpersonal level and an obstacle for its use on a technical one. I expect I'll be using cmake until I drop dead, frankly
.. fun thing .. we hacked around meson not having a way to call a fucking shell command by instead saying that theres a subproject thats "autotools" an then had a hand written shell script called "configure" that just ran whatever the heck we actually were trying to do from there
@Li bet if you show this to a meson maintainer they'd have an aneurysm
@whitequark well you see it does eventually run a ./configure script but it needs to run it with different arguments than the default and it needs to set environment variables and .. a bunch of other shit; and then the configure script in the thing its building actually fails, however it fails in some extra components it tries to build that are not actually needed, it fails because it tries to use itself to build itself; but the version included in the system repos is way too new for that, i _would_ fix it to only build what i need, but that would mean dealing with autotools,
.. so it just runs it, lets it fail then copies out the things it did actually build successfully to the location meson is expecting the build folder to be, then gives a success error code
build systems are great
@dascandy @whitequark @Li I can't speak for this particular issue, as Meson has been able to execute shell scripts since ages.
Forcing some things is a tradeoff. While it does make some strange setups more difficult (maybe even impossible, though that is rare) it makes more important and common things vastly simpler. In Meson you can take two independent projects, use one as a subproject of the other transparently and have it mostly work. In CMake cross-using projects is unreliable at best.
@jpakkane @dascandy @whitequark
none of us could figure out how to do it ..
https://github.com/OpenPSS/SnowPME/blob/main/subprojects/LibPssMono/meson.build
the "env": "CFLAGS" is undocumented feature from what i can tell, found it by reading the source .. (and also didnt even work iirc, we just set cflags in the fake configure script"
i need an extremely specific fork of a very old version of mono-runtime ..
The `env` kwarg is documented: https://mesonbuild.com/External-Project-module.html#add_project
If the env var is not set then that seems like a bug. Though CFLAGS might be special because people might expect them to "pass through" to the underlying build system. It's all terribly complicated and different people expect the exact opposite thing to happen.
Owen Anderson
Josh Simmons@whitequark I only get to hate cmake because in my industry somebody would literally murder you if you tried to use autotools.
@dotstdy please tell me which industry it is (it will influence where I look for work if I ever have to)
F4GRX Sébastien@whitequark we discovered today that the link command for an executable or lib ends up in a link.txt file called from a submakefile via a cmake_link tool or something, and that RM is actually cmake --rm
Also, they recently changed (deb12->deb13) the CMAKE_C_CREATE_STATIC_LIBRARY command from ar rc to ar qc and that it broke our build of a native ios library, the latest xcode choked on the generated .a files. Fuck that shit.
@f4grx the link.txt thing is to avoid length limits on command line arguments (present in both Windows and Linux, though Linux has a much bigger limit)
the cmake --rm is so you can use it on Windows transparently (there's also cmake -E copy and friends, very useful)
R@whitequark @f4grx ... TIL that this trick still existed in the "modern" era
we mostly knew it as a borland / msdos-ish-era trick
@whitequark @f4grx oh is _that_ why large projects such as llvm will bundle bits into .a/.lib files?
Eloy.@whitequark @f4grx oh god this reminds me of the gzipped cli params implemeted at google somewhere...
Baudouin Feildel@whitequark @f4grx that's half of the shit in CMake: working around platform stupid shit. The other half is self inflicted problems (mainly that buildsystem are not a soup of variables). You might think there's a third half and that it is the CMake language. But that would be nice to shit to compare the CMake language with it. No that language is hell, it is trap after trap.
@whitequark @f4grx but despite this I'm working on adding Rust support to CMake. Don't ask why please.
@amdg2 @whitequark oh yes that would make me try rust, because I refuse to learn more build systems.
Tim M@whitequark I'm almost afraid to ask but have you ever actually looked at msbuild, an almost obsessively single purpose automation scripting system that has had C++ building shoehorned into it in the most hacky weird way ever and has 2 very different execution engines (devenv & msbuild) that claim to execute it, and is used very widely on Windows projects because [.. no... I don't know why... ]
@schmerg I have heard some things about msbuild internals and it terrifies me but also makes me curious
gnaggnoyil@whitequark Allow me to introduce Xmake for you.
@gnaggnoyil $workplace uses it and i don't like it so far, but i may be wrong