~eschwartz


#67 create proper release for muon 13 days ago

Comment by ~eschwartz on ~lattis/muon

#66 Fails to detect compiler if CC includes arguments 15 days ago

Comment by ~eschwartz on ~lattis/muon

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

#66 Fails to detect compiler if CC includes arguments 15 days ago

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

#65 Booleans not recognized 16 days ago

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.

#65 Booleans not recognized 16 days ago

on ~lattis/muon

Thanks ~eschwartz!

#65 Booleans not recognized 16 days ago

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

#51 cmake-config.h.in: error extraneous characters on #cmakedefine line a month ago

Comment by ~eschwartz on ~lattis/muon

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

#51 cmake-config.h.in: error extraneous characters on #cmakedefine line 2 months ago

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. :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".

#51 cmake-config.h.in: error extraneous characters on #cmakedefine line 2 months ago

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.

#51 cmake-config.h.in: error extraneous characters on #cmakedefine line 2 months ago

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 like asdf !)(*% abcdef ghi jkl
  • if foo is "falsy", the line is wiped clean, replaced with an #undef foo, and done with