with 2588d1e796
KPMCore is Qt6 only, so any version from 24.01.75 on is Qt6, no need to check for Qt version this way
add missing NO_CONFIG to summaryq
make kpmcorehelper usable for both kf5 & 6, though no section added yet dealing with set to NOT for Qt6
adjust CalamaresConfig to not be hardcoded to kf5
one more var needed in Variant.h, used in PartitionInfo.cpp
adjust QVariant & QtConcurrent use
- On FreeBSD, no KF6 was available
- On KDE Neon Unstable, there are somewhat wonky KF6 packages available
- Adjust CMake to find the KDE Neon versions, then fix the C++ code
This works around older CMakes that refuse to set arbitrary
properties on a target. Instead, use calamares::kpmcore
as the specific indicator that kpmcore was found.
Breaks build of libcalamares, since that needs **something**
regardless of whether KPMcore was found.
- the alias libraries calapmcore and calamares::kpmcore
are always created; if there is no KPMcore, they handle
definitions to signal that.
- upstream kpmcore target is the one we should be testing
to see if KPMcore itself is there (or, use KPMcore_FOUND).
- kpmcore (when used as target "kpmcore") has an interface
include directory that does not contain the "kpmcore/"
subdirectory. But the headers it has installed, assume it
is there (e.g. kpmcore internals use #include <fs/filesystem.h>).
- add an alias at Calamares level that sticks in some more
includes, adds the relevant WITHOUT_kpmcore when it's
not there, etc.
I think we had this (kind of) module a long time ago and it was
removed for over-complicating things; re-introduce one now that
KPMcore is used in 3 different places and all would benefit
from consistent API handling / defines.
