Comment by ~eschwartz on ~lattis/muon
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.
Comment by ~eschwartz on ~lattis/muon
Apropos of nothing, I would usually see -march, specifically, in $CFLAGS.
Comment by ~eschwartz on ~lattis/muon
Muon's compiler detection currently treats $CC as a single filepath to an executable, so it fails to execute
'gcc -march=x86_64' --version
Comment by ~eschwartz on ~lattis/muon
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/955
It still fails later because muon doesn't yet implement the implib kwarg.
Comment by ~eschwartz on ~lattis/muon
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).
Comment by ~eschwartz on ~lattis/muon
That seems like a reasonable solution. It's equivalent to what Meson supports, but with added error-detection.
Comment by ~eschwartz on ~lattis/muon
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. :DBut 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".
Comment by ~eschwartz on ~lattis/muon
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.
Comment by ~eschwartz on ~lattis/muon
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 likeasdf !)(*% abcdef ghi jkl
- if foo is "falsy", the line is wiped clean, replaced with an
#undef foo
, and done with