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