- do not link (explicitly) to Calamares libraries, the CMake
functions do that automatically.
- while here, tidy and remove commented-out-bits
- while here, remove unneeded includes
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.
- point to main Calamares site in the 'part of' headers instead
of to github (this is the "this file is part of Calamares"
opening line for most files).
- remove boilerplate from all source files, CMake modules and completions,
this is the 3-paragraph summary of the GPL-3.0-or-later, which has
a meaning entirely covered by the SPDX tag.
In spite of there being considerable documentation sometimes in the
config file, we go with CC0 because we don't want the notion of
'derived work' of a config file.
The example `settings.conf` is also CC0. Add some docs to
it while we're at it.
The build instructions are not that interesting, it's a toss-up
between CC0 and BSD-2, but because other CMake bits are BSD-2-Clause,
apply that to more CMakeLists. The copyright date isn't all that
accurate, but these are just inconsequential files.
While here, tidy up and get rid of some useless intermediates.
- This makes linking easier,
- Adds the right includes (needed on FreeBSD),
- Lets us drop silly GUI setting for non-GUI tests (I think this was
a side-effect of compiling on FreeBSD, where UI would pull in
/usr/local/include).
- Let's just have one header definining export- and visibility-
macros for Calamares. They are still selected based on the
export flags (*_PRO), just defined in one header instead of two.
- If KPMcore is found -- it requires some other KDE Frameworks but
at least in pre-4.0 versions doesn't check very well for them --
then missing its dependencies is no cause for CMake failure.
Instead, log it nicely and suppress the module.
- provide complete information for feature_summary
- set the right API version when building libcalamares
- report the beta version number when it's wrong
- Starting to centralize utility code for partitioning into
libcalamares instead of scattered and weirdly shared between
modules.
- This particular commit breaks compiling the modules, though.
- The sub-directories under libcalamares (e.g. Utils, ..)
all live in namespace CalamaresUtils (well, except for Logger).
The services (e.g. subdirs other than utils/) live in their
own nested namespace, so partitioning should go into
CalamaresUtils::Partition for consistency.
Instead of relying on a module-specific implementation, use the new
PartitionSize class for storing partition sizes.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
- If KPMCore is not found, don't require the KF5 components
that it would depend on.
- If ECM is found, use KDEInstallDirs always, not just when
the partitioning module is used.
- Use only utils/YamlUtils.h to pull in yaml-cpp and supporting code.
- When compiling with clang, turn off warnings that the system header
for yaml-cpp would generate.
- KDE neon ships a post-3.3.0 KPMCore, with deprecations, but not yet
the KPMCore 4 API, so add another API-version check to handle the
deprecations. Keeps warnings down.
This commit creates a _KiB operator for future use by the partition
module.
It also fixes a typo in one instance of MiBtoBytes(), requiring a couple
extra fixes.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
