Undeclared dependency on glaze

[logrusx]

[60/628] /usr/bin/x86_64-pc-linux-gnu-g++ -DHAS_EXECINFO -DHYPRLAND_VERSION=\"0.53.2\" -DUSES_SYSTEMD -Dstart_hyprland_EXPORTS -I/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/. -I/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/src -I/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/protocols  -march=native -pipe -O2 -std=gnu++26 -O3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -Wno-unused-value -Wno-missing-field-initializers -Wno-gnu-zero-variadic-macro-arguments -Wno-narrowing -Wno-pointer-arith -Wno-clobbered -fmacro-prefix-map=/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/= -fno-lto -MD -MT start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o -MF start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o.d -o start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o -c /var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/start/src/helpers/Nix.cpp
FAILED: [code=1] start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o 
/usr/bin/x86_64-pc-linux-gnu-g++ -DHAS_EXECINFO -DHYPRLAND_VERSION=\"0.53.2\" -DUSES_SYSTEMD -Dstart_hyprland_EXPORTS -I/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/. -I/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/src -I/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/protocols  -march=native -pipe -O2 -std=gnu++26 -O3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -Wno-unused-value -Wno-missing-field-initializers -Wno-gnu-zero-variadic-macro-arguments -Wno-narrowing -Wno-pointer-arith -Wno-clobbered -fmacro-prefix-map=/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/= -fno-lto -MD -MT start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o -MF start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o.d -o start/CMakeFiles/start-hyprland.dir/src/helpers/Nix.cpp.o -c /var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/start/src/helpers/Nix.cpp
/var/tmp/portage/gui-wm/hyprland-0.53.2/work/hyprland-source/start/src/helpers/Nix.cpp:13:10: fatal error: glaze/glaze.hpp: No such file or directory
   13 | #include <glaze/glaze.hpp>
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.

First, this is not declared in CMakeLists.txt. I'm also under the impression hyprpm requires glaze and I've explicitly disabled it.

Second, why do I need Nix helper when I don't use Nix? How do I disable that?

And one more thing. Optimization level is overriden by the build system to -O3 when I have -O2 as my preference.

[jwihardi]

I saw this too and though I was trippin. I thought glaze is only used when hyprpm is built. The CMakeLists seems to just include everything and doesn't even consider if hyprpm arg is enabled or not.

file(GLOB_RECURSE SRCFILES CONFIGURE_DEPENDS "src/*.cpp")

[logrusx]

I reverted the two commits from 0.53.2 that pertain to nixGL and hyprpm on Nix and deleted all Nix stuff and it builds fine.

This should have been hidden behind a macro or something, so that it doesn't bother non-Nix systems.

Of course I could have just installed glaze but that's not how it should be.

Edited to add the commit hashes:

Those are the offending commits: f2a42a7 and 4350f47

Especially for f2a42a7 IDK why somebody would directly include the Nix stuff just like that.

I'm using this patch:

hyprland-0.53.3-remove-unnecessary-nix-stuff.patch

together with rm -rf nix subprojects in my build scripts.

[hyenaheartbeats]

Couldn't build hyprland without doing this, and hyprpm update won't go through which I imagine is related to this.

[logrusx]

You can build it without this, just install glaze prior. I can't see how hyprpm not working could be related to this. But then I don't use hyprpm and none of the users of my build scripts do.

[logrusx]

Updated patch fo 0.54.0

hyprland-0.54.0-remove-unnecessary-nix-stuff.patch

[logrusx]

The above patch works for 0.54.2 as well.

[n-connect]

@logrusx

Thanks for the patch. Before that had the same error around 17-20% of the build and failed early. After remove the nix dir and applied the patch there's no error during build at all, but finally is fails like it below:

Edit: 0.53.2 has the same error, and of course the 0.53.3 patch do not apply, throws an error too. :)

[ 97%] Building CXX object CMakeFiles/hyprland_lib.dir/protocols/pointer-warp-v1.cpp.o
[ 97%] Building CXX object CMakeFiles/hyprland_lib.dir/protocols/fifo-v1.cpp.o
[ 97%] Building CXX object CMakeFiles/hyprland_lib.dir/protocols/commit-timing-v1.cpp.o
[ 97%] Building CXX object CMakeFiles/hyprland_lib.dir/protocols/wayland.cpp.o
[ 98%] Linking CXX static library libhyprland_lib.a
[ 98%] Built target hyprland_lib
gmake[2]: *** [Makefile:166: all] Error 2
gmake[2]: Leaving directory '/tmp/Hyprland/build'
make[1]: *** [Makefile:8: release] Error 2
make[1]: Leaving directory '/tmp/Hyprland'
make: *** [Makefile:24: all] Error 2

Do you have any pointer what to for a fix. Followed the Makefiles, but found no direct connection

[logrusx]

It has nothing to do with the patch. The real error has happened early in the ebuild and you've missed it:

git/hyprland/hyprctl/src/hyprpaper/Hyprpaper.cpp: In function ‘std::expected<void, std::__cxx11::basic_string<char> > doListActive()’:
git/hyprland/hyprctl/src/hyprpaper/Hyprpaper.cpp:179:30: error: ‘CCHyprpaperStatusObject’ was not declared in this scope; did you mean ‘CCHyprpaperWallpaperObject’?
  179 |     auto status = makeShared<CCHyprpaperStatusObject>(manager->sendGetStatusObject());
      |                              ^~~~~~~~~~~~~~~~~~~~~~~
      |                              CCHyprpaperWallpaperObject
git/hyprland/hyprctl/src/hyprpaper/Hyprpaper.cpp:179:64: error: ‘class CCHyprpaperCoreManagerObject’ has no member named ‘sendGetStatusObject’; did you mean ‘sendGetWallpaperObject’?
  179 |     auto status = makeShared<CCHyprpaperStatusObject>(manager->sendGetStatusObject());
      |                                                                ^~~~~~~~~~~~~~~~~~~
      |                                                                sendGetWallpaperObject
git/hyprland/hyprctl/src/hyprpaper/Hyprpaper.cpp:183:13: error: ‘class Hyprwire::IClientSocket’ has no member named ‘roundtrip’
  183 |     socket->roundtrip();
      |             ^~~~~~~~~

And this is a breakage in the main branch which is currently present.

[logrusx]

#13358

I seriously don't want to waste anymore time with this. I suspect ultimately I'm going to quit packaging it for Gentoo and move to something else.

[n-connect]

@logrusx

Thanks for your input and help, also mentioning the #13358. All needed to find the root cause(s). I build Debian binary packages, but .tar.gz format only, no deb files (yet?). So there's an already working predefined Docker for build purposes. All the necessary packages there to enable the builds of all Hyprland ecosystem. So only the delta needed for 0.53[.3].

Your patch was the key, again thank you!

The other components were missing are the various hyprwire packages + one. In Debian derivatives they called:

• libhyprwire-dev hyprwire-scanner
• also needed to upgrade one existing: libxkbcommon-dev
• and install another new libmuparser-dev

It should be something similar in Gentoo I believe, minus the binary package releases of course. All the hyprwire ones are 0.3.0-x (-x is the distrib's own release number)

Additional key points:

• cloning the hyprwire project from github and installing back into the build system did not work, only the above binary packages' install. I'm not sot sure how to apply this info to your Gentoo build, but for other distros it could be important.
• also the lack of install of hyprwire-scanner gave a very early error, rigth at [0%] which I've missed -> as you pointed out, with a different one - so I've rechecked. My last issue with the 97% percent build fail was caused by this.

In one line apt install libxkbcommon-dev libmuparser-dev libhyprwire-dev hyprwire-scanner

The glaze related part look like this:

-- glaze dependency not found, retrieving v6.1.0 with FetchContent
-- hyprpm is enabled (NO_HYPRPM not defined)
-- Testing is disabled
-- Configuring done (62.2s)
-- Generating done (0.1s)
-- Build files have been written to: /tmp/Hyprland/build
cmake --build ./build --config Release --target all -j`nproc 2>/dev/null || getconf NPROCESSORS_CONF`
gmake[2]: Entering directory '/tmp/Hyprland/build'
[  0%] Generating /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_core-client.cpp, /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_cor
e-client.hpp, /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_core-spec.hpp

I hope it will help for others too.

[logrusx]

hyprwire-scanner - there's no such repository. Where did you get that from?

[n-connect]

Yeah I know, my reason to fail too.

In Debian they have built it as a separate package - whatever the reason, hence the issue of missing install it in the dev env. Although I'm sure it will be needed on the production/running env. too.

My usual attempt of:

1. Pre-compile the very packages and its dev/header parts - in the dev. Docker itself,
2. Than installing them into the same dev env. failed with hyprwire, I don't know why. Install/build FAQ on hypr.land with 6 dependencies listed in the build order is missing hyprwire - yet(?).

HyprLand just complained about its still missing... After that I realized there is ALREADY a hyprwire and hyprperwire-dev package in Debian, however the whole code's first release 16th Oct 2025. No small feat!

Anyway, the scanner code is in the main hyprwire repo, let me know if you could make it work with precompiling

Edit: Thesid package (the codename for the actual unstable branch within Debian) for hyprwire-scanner

[logrusx]

I don't like to play with development branches. It causes me to much trouble for no benefit at all. To take advantage of portage, Gentoo's package manager doing the building stuff for me, I need to install it system-wide. It takes time and work to build while I need that system up and running and completely functional.
The reason for me digging into this is the issue you were experiencing, however I'm not willing to go deeper at this point, especially in Debian's nonsensical packaging.

[n-connect]

I don't understand what you mean on development branches, or why it is came here.
We are on stable releases (in LTS mode, with backports if necessary), on those Unix-like stuff where it is applicable.

The sid link was added for you as a quick google find to see it as a sample:
This is not just Hyprland asking for hyprwire-scanner during build, but you can find binary packages with such name, contrary its extreme young lifetime. Being just a 1.5 years Hyprland user / builder on a non-rolling distro base, it still amaze me how fast this project goes forward. And actually this is the reason why they dropped it out from Debian altogether - hence the builds

The actual issue is not distro related, but Hyprland's own mess with the actual build framework - and how it handles the new hyprwire dependency (and the NixOS stuff, plus your patch and so on). As far as I know it started with v0.52.x as the previous builds did required neither hyprwire, not were issues with NixOS stuff - at least in our experience.

This output is the reason I got the "knowledge" there's such a separate thing as hypr-scanner beside hyperwire what Hyprland needs for its build - and later for run.

So now with this issue and our posts everyone will have it, great.

In text:

gmake[2]: Entering directory '/tmp/Hyprland/build'
[ 0%] Generating /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_core-client.cpp, /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_core-client.hpp, /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_core-spec.hpp
/bin/sh: 1: hyprwire-scanner: not found
gmake[4]: *** [hyprctl/CMakeFiles/hyprctl.dir/build.make:74: /tmp/Hyprland/hyprctl/hw-protocols/hyprpaper_core-client.cpp] Error 127
gmake[3]: *** [CMakeFiles/Makefile2:1200: hyprctl/CMakeFiles/hyprctl.dir/all] Error 2
gmake[3]: *** Waiting for unfinished jobs....[ 0%] Generating /tmp/Hyprland/protocols/alpha-modifier-v1.cpp, /tmp/Hyprland/protocols/alpha-modifier-v1.hpp

As screenshot:

Again thanks for the patch and good luck for the Gentoo stuff

[logrusx]

I've corrected my above replay:

I don't juke to play with development branches.

becomes:

I don't like to play with development branches.

Maybe the text prediction on my phone made that up.

I don't understand what you mean on development branches, or why it is came here.

Development branch is where active development happens and source is not ready for release yet. Release branches are stable.

We are on stable releases (in LTS mode, with backports if necessary), on those Unix-like stuff where it is applicable.

I don't know what you're talking about. The issue you have happens in the main branch which is the development branch. That's why I brought it up. The last release - 0.53.3 does not have that issue because it's based on hyprwire-0.2.1. I din't bump it up to 0.3.0 because it had a changed so version which probably means incompatibility.

The actual issue is not distro related, but Hyprland's own mess.

I agree with that. And when I proposed improvement to that mess I was simply asked "Why?". Very weird.

This output is the reason I got the "knowledge" there's such a separate thing as hypr-scanner beside hyperwire what Hyprland needs for its build - and later for run.

I don't understand this. It seems to be some Debian specific stuff.

Anyway I'm not dealing with Hyprland until the next release. And if this mess continues I might not deal with it at all after that point.

[n-connect]

I don't understand what you mean on development branches, or why it is came here.

Development branch is where active development happens and source is not ready for release yet. Release branches are stable.

You do realize the context how and what you wrote completely mixed github repositories and its branches vs Linux disttributions different type of releases. On the other hand Hyrpland is one of the fastest changing and evolving codebase, so talking about dev banches alone gives no directions. But answering to what I wrote geared towards to the distro "dev branch", but made no sense anyway. Therefore I did not understand how is it come here.

We are on stable releases (in LTS mode, with backports if necessary), on those Unix-like stuff where it is applicable.

I don't know what you're talking about. The issue you have happens in the main branch which is the development branch. That's why I brought it up. The last release - 0.53.3 does not have that issue because it's based on hyprwire-0.2.1. I din't bump it up to 0.3.0 because it had a changed so version which probably means incompatibility.

Yepp, this is the round I answered to you about something you wrote, but you actually wanted to wrote something else. The above info if about business use of Linux, or if you like mission critical Linux - where you can't let stuff just broke down cause of an update. what companies choose to use on systems which directly makes money. Vs. dev branch stuff

This output is the reason I got the "knowledge" there's such a separate thing as hypr-scanner beside hyperwire what Hyprland needs for its build - and later for run.

I don't understand this. It seems to be some Debian specific stuff.

No it is not - that's the main point. Hyprland's build [framework/system] in this version is a mess. If one do compiles it on *BSD, or OpenIndiana they'll have the very same issue, and needs your patch and install all the hyprwire codes/packages whatever and however they grouped or not - including the scanner parts..

From my side the idea to make a public descripton & key information about the error in the topic it raised and solved - fulfilled. It's done so I'm finished with this topic. Safe to you can close it.

[logrusx]

I get the feeling we're taking different languages here, despite using English words. At this point continuing on seems pointless. It seems to be some kind of language barrier.

[logrusx]

In fact I'll answer only one of your points because it looks like a misunderstanding of what my patch does:

If one do compiles it on *BSD, or OpenIndiana they'll have the very same issue, and needs your patch

My patch is not needed to build Hyprland. It's needed to not build useless stuff. You could just install glaze but then you'll be building stuff you don't need and don't want. Which to a certain extent is acceptable but it'll become a problem over time.

My patch removes Nix related sources which if not removed can build and exist fine on systems which don't need it. And the only dependency it would bring in is not some Nix stuff but glaze, which is close to nothing. But I don't like that and consider it a bad style.