| 19 Feb 2026 |
 emily | cmake/QtProcessConfigureArgs.cmake sets set(QT_FIND_ALL_PACKAGES_ALWAYS ON) which disables the platform guards on looking for X11 and Wayland libs | 11:58:27 |
| emily | but I don't know if we end up using that file either :) | 11:58:59 |
| emily | anyway | 11:59:38 |
| emily | I believe https://github.com/NixOS/nixpkgs/pull/477359 was the culprit | 11:59:45 |
| emily | because withWayland ? lib.meta.availableOn stdenv.hostPlatform wayland, is now triggering | 12:00:07 |
| emily | we could presumably add an additional guard there but I am inclined to revert that PR for now because I'm not convinced we should be carrying a somewhat invasive downstream patch to libwayland anyway | 12:01:52 |
| emily | well. I suppose we can't revert because that would cause Linux rebuilds | 12:04:02 |
| emily | I take it a wayland rebuild is out of the question at this point? | 12:04:12 |
 vcunat | So we override withWayland to false on darwin? | 12:05:01 |
| vcunat | (Does wayland even make sense on darwin?) | 12:05:24 |
| emily | it's probably not a good thing if ~everything doing withWayland ? lib.meta.availableOn stdenv.hostPlatform wayland needs special-casing for Darwin because nothing expects Wayland on Darwin | 12:05:35 |
| vcunat | * So we override withWayland to false on darwin, at least for now? | 12:05:38 |
| emily | shrug
This package is vital for macOS wayland compostors.
I am currently working on a wayland compositor for macOS, and this would help me reduce reliance on downstream custom derivations of libwayland.
X11 on macOS is a thing, Wayland on macOS could be too. in practice it is not
| 12:06:04 |
| vcunat | In that case we'd... remove darwin from wayland.meta.platforms probably | 12:06:08 |
| emily | so I'm not inclined to put much work into it to keep Darwin working. | 12:06:11 |
| emily | right, this PR was specifically meant to make it build on Darwin again. | 12:06:22 |
| vcunat | That's one thing. | 12:06:41 |
