Some tests -- notably the keyboard module -- need to have the
QRC for the module loaded as well (e.g. because of data in the
QRC). Add a RESOURCES parameter to calamares_add_test()
like calamares_add_plugin() already has, to build the
resources into the test.
Keyboard test now passes, since it was missing the data for
lookups before.
- *secretly* this is already done in the KF5 i18n modules,
so the resizefs was already requiring FindGettext.
- we don't actually use the gettext modules' CMake macros,
so explain why in the module.
- there's no need for a macro that is going to be used once,
especially if there's only one place it can be called.
- expand it in place and remove it from the installed CMake
module
- 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.
The intended license for the CMake modules is BSD-2-Clause;
there's no desire to restrict what can be done with these,
and CMake modules are generally 2-clause licensed.
When CMake runs, configure_file() will clobber the config files in
the build/ directory, which is annoying during testing: you need
to keep making the same edits, or edit the source.
- Introduce new behavior: the config file is **not** overwritten unless
the source file is newer. This means that edits to config files
in the build directory are preserved.
- If INSTALL_CONFIG is **on** then the files are clobbered anyway (the
source is considered new regardless).
Previously, we check for RCC support every single time CMake runs.
This is slightly wasteful, and it wasn't being done right anyway.
But it's moot because:
- Calamares supports back to Qt 5.9
- Qt 5.9's version of rcc (at least, 5.9.7) **does** support the
command-line argument `--format-version 1`
- Everything newer does too.
Simplify translations a little, too: just use autorcc rather than
building things by hand.
- Only copy over branding files if they are newer
Typically I have KDevelop open while working on Calamares; if I
am editing settings in `branding.desc` in the build directory,
then every time KDevelop runs CMake in the background, my
changes (for testing branding things!) would be overwritten.
Don't do that.
For normal builds with a clean build directory, this doesn't change
anything since the target is missing; changing a file in the
source directory **will** copy it over the build directory version.
- The variables that are set for out-of-tree builds are prefixed
with to avoid name clashes; make the module-infrastructure
respect those instead of the in-tree variable names.
- .. and then duplicate the in-tree variables to the out-of-tree
variables, so we only need one set of module instructions.
- Add the Calamares CMake-modules to the search path automatically
- Export to CalamaresTargets.cmake and use namespace Calamares::
- Document imported targets
- Find Qt, because the translations machinery will need macros from that
- The installed lib links to IMPORTED libraries from KF5, so we need
to find them (again) as well.
- The Python configuration tests sometimes need extra setup, so
do that through a CMakeTests.txt file in the test directory.
- Patch up existing tests:
- grubcfg needs /tmp/calamares/etc/default to exist
- rawfs won't work on FreeBSD because of differences in /proc
- If a module has tests/#.global or tests/#.job, these are used
as arguments to a test-run of loadmodule (which reads them
and runs the module with that configuration).
- This makes the old python-loading test and test-runner entirely
obsolete, so remove them too.
- 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).
This is an ugly hack, using Bill Auger's support for Job weights.
The unpackfs job is arbitrarily awarded a weight of 12. That makes it
(in a Netrunner install) use progress from 12% to 40% or so, overall,
as all the files are unpacked.
Also fixes bug reported by Kevin Kofler that unpackfs was only reporting
progress when it hit an exact multiple of 100 (instead of over 100).
SEE #1176
- Copy the .qm files (compiled translations) into the build
dir as part of the build process. This is independent of
**installing** those same translations, but does allow
the translations to be used by Calamares when run from the
build dir for testing.
CMakeModules/BoostPython3.cmake: Also try e.g. "python37" as the module
name, because Fedora 30 switched from the e.g. "python-py37" format to
that. Otherwise, Boost::Python3 cannot be found on Fedora without
manually setting CALAMARES_BOOST_PYTHON3_COMPONENT.
- Loading the module will check Python modules for syntax,
and C++ modules for symbols. This would be a good idea,
except for where it calls exec() and does things to the
running system. Most modules are harmless with an empty
config, but you never know (e.g. a process module).
- The auto-generated code produces a lot of warnings from
Clang 8; this obscures the more meaningful warnings from
actual Calamares code, so tone the warnings down.
- For Clang, set CALAMARES_MOC_OPTIONS.
- Add convenience CMake function for automoccing. It applies
the options as needed to a given target.
- Remove the commented-out cruft and the whinging
- Fix use of COMPILE_DEFINITIONS with a list passed in
- Remove unused arguments (TYPE, TARGET)
- Document calamares_add_library
- Document how to use COMPILE_DEFINITIONS (in calamares_add_plugin)
- document new variable from the CMake module
- use it in libcalamaresui to simplify #include'ing the
header for the "all" extension.
Suggested by Denis Proskurin.
Switching to INSTALL_CONFIG=OFF breaks tests by not having them
in the build directory. Some logic was coupling not-installing
to not-using-in-build-dir too closely.
Although the NO_INSTALL keyword could be specified for
Calamares plugins, it didn't actually do anything. Now
it does. A NO_INSTALL module does not install configs
or libraries.
Adriaan de Groot
Callum Farmer
Kevin Kofler