- Using project() to set up the version is idiomatic for CMake
and more standardised than doing it by hand. Do retain the
RC flag, because that's used in other parts of versioning.
- Settings is just a settings class, no UI involved, so
move to libcalamares where it can be used also from
system helpers.
- YAML utilities are useful at a lower level of the stack, too.
The install-bits branch commit 83639b182b
dropped .so-versioning for libcalamares and the creation of the Python-
support symlink. This broke KDE Neon dev-unstable because the embedded
Python can no longer find libcalamares.
Installing unversioned .so's straight to LIBDIR is also not a good thing
(according to Debian), so revert to the original scheme with versioned
.so and a Python-support symlink.
Medium-term fix is to install unversioned straight into LIBDIR/calamares
and fix up the RPATH for the executable.
- Applies to libcalamares and libcalamaresui.so, install with no
version, just the bare .so. Since Calamares doesn't do versioning
anyway, and its plugins should be re-compiled for any change,
putting them in lib as unversioned .so's should make Calamares
happy and silence lintian.
- Move CommandList so it can be used from more modules than
just ShellProcess
- Allow a CommandList to run itself. This centralizes
code for executing one or more commands and simplifies
the ShellProcess module.
Various small cleanups:
- mention instance id in log message
- code formatting / style
- This is only a partial solution to warnings caused by third-party
code, since #including the headers from other sources won't apply
the warning-suppressions.
- Flags are not applied when building the source as part of a larger
target, but are on re-building just one object (it seems -- CMake
issue to track down).
Thanks to Kevin Kofler for pointing out what I'd forgotten about
source-file flags. While at it, introduce a generic mechanism for
suppressing warnings in third-party code.
Mostly reverts 4930484931
These job plugins work similarly to view modules, with the following
differences:
* These jobs need to link only libcalamares, not libcalamaresui. For
this reason, PluginFactory was moved from libcalamaresui to
libcalamares. (It depends only on QtCore.)
* Instead of deriving from ViewModule, derive from CppJob (which is a
subclass of Job).
* Like process and Python jobs, a job plugin is a single job, whereas a
ViewModule can generate a whole list of jobs.
The CppJob and CppJobModule classes are new. In Module::fromDescriptor,
the combination type=job, intf=qtplugin is now supported and mapped to
CppJobModule.
Point the lib/calamares/libcalamares.so symlink for the Python modules
directly to the versioned lib/libcalamares.so.VERSION library rather
than to the lib/libcalamares.so symlink. This allows distributions to
install the lib/libcalamares.so symlink to a development package and
only ship lib/libcalamares.so.VERSION and lib/calamares/libcalamares.so
in the runtime package. It is also marginally faster (because only one
level of symlinks has to be resolved instead of two).
(I know this works because I have been manually fixing up this symlink
in the Fedora specfile so far.)
Rename PythonJobHelper ==> CalamaresPython::Helper.
Add QVariant to boost::python::object conversion functions.
Rename some constants in the libcalamares Python API.
Created a Boost.Python module interface in libcalamares.
Added a PythonJob wrapper and exposed it in the Python module.
Rename target calamareslib ==> calamares so in Python it's libcalamares.
Python-related classes in libcalamares that aren't exported as C++
symbols are now in a CalamaresPrivate namespace.
Import the libcalamares python module into every Python script before
running it.
Added Python error handling to PythonJobHelper.
Added some more testing code to dummypython module.
