Bismuth-Forge / bismuth

KDE Plasma add-on, that tiles your windows automatically and lets you manage them via keyboard, similarly to i3, Sway or dwm.
https://bismuth-forge.github.io/bismuth/
Other
2.41k stars 92 forks source link

[DEV]: Compile problem on different architectures #409

Open onuralpszr opened 2 years ago

onuralpszr commented 2 years ago

Summary

I was trying to build bismuth on different architecture on fedora and some of them fail due to problem of "Too many signals to create unique bit masks" messages comes from kconfig_compiler and here is the relevant line

https://invent.kde.org/frameworks/kconfig/-/blob/master/src/kconfig_compiler/KConfigHeaderGenerator.cpp#L224

Here is the relevant build errors : https://koji.fedoraproject.org/koji/taskinfo?taskID=90594514

One of the build.log URL : https://kojipkgs.fedoraproject.org//work/tasks/4538/90594538/build.log

I wasn't sure where to report maybe it is a problem of bismuth If not I can go report into kconfig but please check it.

Workaround : I turn off those architecture from build for now once it is fixed, I will re-enable them as well.

Additional info

No response

pinotree commented 1 year ago

TL;DR: most likely a bug in kconfig_compiler, fixed in kconfig 5.100.0 (both [1] and [2]).

This kconfig_compiler bug affected all the architectures, not only those when it exited with "Too many signals to create unique bit masks". In case of architectures that "built" (e.g. x86_64), the header for the KConfigXT-based configuration was miscreated:

    enum {
      signalEnableTileLayoutChanged = 0x1,
      [...]
      signalLimitTileWidthChanged = 0x80000000,
      signalLimitTileWidthRatioChanged = 0x0,
      signalNewWindowAsMasterChanged = 0x0,
      signalExperimentalBackendChanged = 0x0,
      signalBismuthEnabledChanged = 0x0
    };

The 0x0 bitmask means it was never signaled that a property was changed, and thus its "changed" signal was never emitted. This affected the following configuration keys:

I don't know whether this means that certain bits in Bismuth didn't work properly before, or whether this was noticed.

After a bit of debugging, I found the bug (at least I hope there are not others) in kconfig_compiler: it wrongly checked for the number of maximum signals to generate bit masks for, using wrong data types. You can read the "gory details" in the commit message of [2]. According to my local testing, the output is properly generated now, both on architectures where kconfig_compiler did not fail, and where it exited with the aforementioned error message. I also backported the fix (both the two commits) to Debian unstable, and Bismuth built fine on all the architectures.

[1] https://invent.kde.org/frameworks/kconfig/-/commit/1ab5e4898de5d8a274f6fa83d9d1debbd3287444 [2] https://invent.kde.org/frameworks/kconfig/-/commit/6c0acf3be392414bbdfbb7473aa842ee59d65f3d