- Don't use the ${kfname} package itself, use it as a prefix for
specific components of that package (e.g. ${kfname}CoreAddons)
- Use TYPE to indicate required packages, rather than using
REQUIRED in the find_package call, to more-helpfully collect
missing requirements.
1- Need to be careful switching dependencies from REQUIRED to OPTIONAL
2- Don't do ECM REQUIRED all over the place
3- Workaround neon CI not having KCrash (which translated to KF5 not
found, which translated to a missing REQUIRED dependency, see 1).
The find_package() in the plasmalnf module seems to mark KF5 as not-found,
because one component is not found right then -- after that, CMake-time
fails because KF5 is still-required and not-found.
- 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
Having an up-to-date settings.conf in the build directory
makes `calamares -d` in that directory much more predicatable.
This should not have used CMake command `install()`.
FIXES#2075CLOSEs#2079
- this would be the first 3.3 release, scripts still needed
cleanup to handle all the changes in 3.3
- support "-alpha1" kinds of designation
- support more versioning information in the headers
On FreeBSD, at least, `find_package(Boost COMPONENTS python)`
doesn't work well, while `find_package(boost_python)` does the job.
Be somewhat more flexible: look for boost_python first, assuming
it pulls in the rest of the Boost bits it needs.
RC (in the 3.2 branch) and RELEASE_MODE are inverted, logically,
but the change to the CMake check wasn't properly inverted.
This only matters if you try to build Calamares in the src-dir,
which is something I never do anyway.
