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