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