Note that in 3.2 branch, the version in CMakeLists now changes just before
the next release, not in post-release housekeeping. That is because
the CALAMARES_VERSION_RC remains 0 (release mode), by convention.
(cherry picked from commit aa09664601)
Since this CMakeLists.txt writes out a C program, the formatting
is a bit weird; just start the written TU with a blank line to
make gersemi happy and keep the C-code aligned.
To avoid git complaining about duplicate worktrees, detach
the temporary trees. To avoid python modules translations
changing order (depending on how find traverses the tree),
sort the filenames before extraction.
- find the best score and match relative to a specific
set of parts; make it easy to update the country-setting
- look for a complete match, or best match, with three
country settings
Argument *text* is an addition in 3.7, while the Calamares 3.3
branch supports Python 3.6 and later. Use the 'backwards compatibility'
name of the parameter, *universal_newlines*.
Cherry-picked from 33961ff6f (in the 3.2 branch, though, Python 3.3
is supported).
- Put this in a method of its own even though it's used
only once, so we can put a good name on it.
- If there are no FS choices (e.g. the sample settings file)
then there is no combo-box, and the check was crashing.
FIXES#2029
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.
- wrangle the test framework so it hands the same data to
two different collections of tests; do KDE neon and FreeBSD
separately so it's clearer which lookups are being done
(and a failure in one doesn't prevent the test of the other).
- 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).
- FileSystem.h depends on KPMcore and only compiles when
KPMcore is present; it can use KPMcore identifiers.
- Global.h doesn't.
- Move the few functions introduced into Global.h that need
KPMcore, to FileSystem.h instead.
When KPMcore is present, the calamares::kpmcore wraps that
and provides suitable API detection. If KPMcore is not
present, the same interface library provides -DWITHOUT_KPMcore.
- 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.
