@Haelwenn /элвэн/ :triskell: So which meson command do I run to see all -D options mpv can take?

@Haelwenn /элвэн/ :triskell: That's a good point. For autotools there's no chance for it to ever get solved, as it's a stable and "finished' system. Nobody's gonna change this - even though it'd be quite feasible to always record the failed command and display it, even in autotools' m4 based design.

meson I had issues debugging as well in context of mpv's use of it. It's nice that it actually does decide to log the error, but sadly meson has other serious issues, such as having no useful --help that lists all configurable options of a project (so I have to dig into build sources etc. for that, as meson configure --help doesn't list them, unlike ./configure --help).

Of course, meson shares this issue with basically all modern build systems, and yet this is something so elementary that lots of end users of a project need. cmake may have ccmake but it often doesn't show even half the options a project defines...

In my opinion the issue of all those build systems is that they're intended for the small team of project developers, and they totally ignore the much larger group of users who just need to run the build system to compile a project by someone else. These users should not need to learn about the build system. They should be able to get all they need from --help and man pages.

@Haelwenn /элвэн/ :triskell: I don't think it's even possible to make a build system that forces the text messages to be semantically correct. Rather, autotools is already as good as it gets there - at least you can read config.log, and if even that lies, you can run it in sh -x. Then there's no possibility for lies left.

All this of course only because some odd people believe that outputting the exact command that failed is somehow bad and user unfriendly... :(

@Haelwenn /элвэн/ :triskell: Trust me, debugging cmake stuff is worse... but I get you, yes.

config.log should contain the real commands run though. I hope.

@Haelwenn /элвэн/ :triskell: The point of the test:


dnl Some versions of `objcopy -O binary' vary their output depending
dnl on the link address.
So this is less of an autotools issue (except for the dumb dnl spam), and more of an artifact of a broken linker from 2002.

Sadly I can't find history of this check (which would likely tell which objcopy version is broken) - this check is there since the initial import.

Looking at the other build scripts, when building for PC/MBR (i386-pc), it does use a similar invocation in the actual build. A build for x86-64-efi may work anyway, so you can just workaround by making the addresses in acinclude.m4 bigger (the test only relies on them being different, not small).