Featured image for Today's Dev #13

Today's Dev #13

November 25, 2024

In Today's Dev #10, I ended the post by mentioning that I was still getting the linker issues in the QtWayland code having undefined references to the related generated C client code and header. Keep in mind, this was also something that my friend Neal and I looked at for several hours on Today's Dev #3 as well. Well I asked in the KDE KWin Matrix room (since they seem to be the most in-depth example of QtWayland and the KDE folks are always super cool and helpful) and asked if anyone could help a guy out. David and Xaver were kind enough to jump in and take a look at my budgie-daemon v2 code. After some back and forth, David stripped the project down to literally just a main.cpp file and directly added the generated qtwaylandscanner sources. That is when he noticed that it wasn't including the C/H files at all! Yea, that'd do it. Kinda hard to have a reference to functions if the files aren't being added. But why? My CMakeLists.txt project definition specified LANGUAGES CXX which means it will only accept files of that given type. It does not warn about files it will not include. I was under the impression it'd be leveraged for checking if the tooling required for CXX was available (e.g. clang++ or g++). Nope. Not at all. But hey, today several of us learned! Removing that languages restriction did the trick! Finally got it to compiling, noticed no events were coming in, fixed my WaylandOutputManager not actually setting the properties of QtWayland::zwlr_output_manager_v1, re-added the necessary wl_ calls for dispatch and roundtrip, and started successfully getting events including a new WaylandOutputHead. Just need to start fixing these segfaults! Hopefully won't be as painful as the linker shenanigans, right? 😄 This is what I would call a "failed successfully". This different kind of failure is one I seriously welcome. Massive thank you to David and Xaver for their help 👏
Did you know?
You can follow me on Bluesky, Mastodon, or Threads!