This has been discussed in the past, for example at https://lists.sr.ht/~lattis/muon/%3CwPjhrtnauq3W6yQoMO8fxIzXjnU5BJkZl9cMW9apk_qlIneI-T9R3KGF1kmEps0B9UKKr6Frn4FN4M_gw-70we6NtbbV73Yh5_HF-A5Magc%3D%40protonmail.com%3E#%3C20211031032719.ysf4isb6rvefvequ@hostomei%3E

It may very well be time to finally create a stable release.

Apropos of nothing, I would usually see -march, specifically, in $CFLAGS.

Muon's compiler detection currently treats $CC as a single filepath to an executable, so it fails to execute

'gcc -march=x86_64' --version

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/955

It still fails later because muon doesn't yet implement the implib kwarg.

Thanks ~eschwartz!

This is an xorg-server bug, Meson expects actual boolean values there (and better type-checking will eventually come -- this will stop working in Meson).

That seems like a reasonable solution. It's equivalent to what Meson supports, but with added error-detection.

If the goal is to only support #xxxdefine TOKEN and error out in any other case "to help people fix their configuration files", then well, people can fix their configuration files by using #mesondefine, which has this reasonable behavior. :D

But the point of cmakedefine was ostensibly to support reproducing cmake's own chaotic format, so, logically, it makes sense to either support "whatever cmake does" or "error: don't use the cmakedefine format, it's terribly confusing".

Actually my explanation was a rebuttal to ~lattis' suggestion to be stricter. Muon is broken in terms of support for cmakedefine. Meson is also broken, but it is less broken; Muon will never work correctly, Meson will work correctly if and only if a cmakedefine has exactly two tokens, one being "foo" and the second being "@foo@".

Again: cmake supports a very large amount of entirely ad-hoc logic. As ~lattis points out:

For example, this is valid:

#cmakedefine foo @baz@ asdf !)(*% abcdef ghi jkl

Meson will only look at foo and output something like: [...]

Specifically, Meson will only look at foo, and discard the rest of the line while assuming that it is @foo@ and performing the same actions that cmake would perform if it were indeed @foo@. If Meson's assumption is correct, then we are safe. We did the same thing that cmake would do.

This is an interesting one, see the cmake documentation: https://cmake.org/cmake/help/latest/command/configure_file.html#example

cmake compatibility is a hairy monster, and Meson's brave/foolhardy attempt to support it may well be entirely broken.

AFAICT, cmake expects to do the following:

• if foo is "truthy", #cmakedefine -> #define and continue processing replacement tokens on the rest of the line, whether that is @foo@ or @baz@ or unreplaced contents like asdf !)(*% abcdef ghi jkl
• if foo is "falsy", the line is wiped clean, replaced with an #undef foo, and done with