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

@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

@whitequark

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

@Li that's horrifying
@Li reminds me of how in order to cross-compile one of the things i did for ocaml-cross-ios, i eventually ripped out the entire build system (several thousand lines of ocaml, iirc) and replaced it with like 10 lines calling ocamlc directly on the files it actually built
@whitequark @Li @jpakkane what do you think?

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

SnowPME/subprojects/LibPssMono/meson.build at main · OpenPSS/SnowPME

PlayStation Mobile Emulator. Contribute to OpenPSS/SnowPME development by creating an account on GitHub.

GitHub

@Li @dascandy @whitequark

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.

External Project module