Bug 426219

cmake -DINSTALL_UDEV_RULE=Off

Should probably be added to the kdesrc-build.

As of commit cbf96256, the suggested CMake option is already passed to bluez-qt. Someone else has reported this as a bug on IRC. Could I ask how kdesrc-build was installed (cloned from git or distribution packages) and how the kdesrc-build configuration was generated (kdesrc-build-setup, modification of the sample configuration, kdesrc-build --initial-setup, something else)?

I installed it from Archlinux AUR:
https://aur.archlinux.org/packages/kdesrc-build-git/

I used kdesrc-build-setup and went through the graphical guide to set it up.
I only had problem that it was unable to find module dir which was solved by setting PERLLIB env var to the installation directory.

The problem was caused bu not selectiong "frameworks" in kdesrc-build-setup TUI.
This caused it to not include the configuration file into ~.kdesrc-buildrc file.
This paired with option "include-dependencies" which pulled the frameworks which I did not wish to build (that is why I did not check them in TUI) but were still built and such created this error.

There could be a little warning ar a whole page with yes/no to include dependencies with explanation.

Git commit 2317c3a32e5aee1e926bd912275fd2149757f69a by Michael Pyne.
Committed on 27/09/2020 at 19:15.
Pushed by mpyne into branch 'master'.

setup: Make include-dependencies optional, show module groups not chosen.

My hope is to make it easier for new users to understand how to add
module groups if they are desired later, since there has previously been
no generated note or warning in the generated kdesrc-buildrc if the user
chose no major groups.

In this case we had a user who, even though they didn't select any
module groups, still had kdesrc-build trying to build bluez-qt due to
include-dependencies being set to 'true' (the default). However bluez-qt
needs a CMake option to be passed to build with kdesrc-build; this
option isn't set unless the kf5-frameworks-build-include file is read
in.

That fix will happen in a separate commit, this should hopefully make it
easier to read through the generated kdesrc-buildrc in any case.

M  +74   -39   kdesrc-build-setup

https://invent.kde.org/sdk/kdesrc-build/commit/2317c3a32e5aee1e926bd912275fd2149757f69a

Git commit ed1545b71654c7e9dc3f3ca65e0c29ef1f6d92c5 by Michael Pyne.
Committed on 27/09/2020 at 19:52.
Pushed by mpyne into branch 'master'.

setup: Break out common 'options' blocks for kdesrc-build-setup to always use.

This change should address the immediate breakage that a user had when
using kdesrc-build-setup, choosing no major module groups, and then
using kdesrc-build to eventually build bluez-qt.

In that case, bluez-qt had an 'options' block in
kf5-frameworks-build-include to address the error he'd experienced,
however since kdesrc-build-setup didn't generate a include to that file,
the options weren't picked up either. kdesrc-build later found the
module via include-dependencies and built it anyways.

To fix this, break out "always-set" options into a dedicated file
(kf5-common-options-build-include) and include that from
kdesrc-build-setup-generated files always.

I moved these from kf5-frameworks-build-include so I added an include
from that file back to kf5-common-options-build-include for backwards
compatibility for existing users. This relies on duplicate options
blocks continuing to work (similar to C++'s One Definition Rule) so I've
documented that in the code for now.

M  +1    -0    CMakeLists.txt
M  +10   -5    kdesrc-build-setup
A  +19   -0    kf5-common-options-build-include
M  +4    -15   kf5-frameworks-build-include
M  +2    -0    kf5-qt5-build-include
M  +2    -0    kf5-workspace-build-include
M  +5    -0    modules/ksb/Application.pm
M  +6    -1    modules/ksb/FirstRun.pm

https://invent.kde.org/sdk/kdesrc-build/commit/ed1545b71654c7e9dc3f3ca65e0c29ef1f6d92c5