- 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.
- Avoid crash due to invalid iterator, when modules
are removed due to missing requirements.
- Simplify code, factor out the determination of
which required modules are missing.
- Move the actual checking into a separate object with some lifecycle-
management signals.
- Right now this is still single-threaded and blocking, so no net gain.
- Use DATA for the qml and branding directories (looks for qml/
and branding/<name>/ in those directories).
- Use CONFIG for the global settings and module settings (looks
for settings.conf and module/<name>/ in those directories).
FIXES#941
- Be more verbose when things go wrong while loading module-
configuration files.
- Allow more forms of paths to be specified. In debug mode, this
is mostyle helpful for the module test-loader.
- 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.
- Similar to the refactorings in Calamares proper, just split out
collecting the search paths into a static function. This makes
it a little easier to find places that will need expansion for
more-than-one-config-directory.
- There is more to failing out of loadModules() than just
emitting modulesFailed, so instead share the failure
code with the code after loading modules -- but don't load any.
- Module dependency-checking is done in two phases:
first, catch any unknown modules that are listed
in *requiredModules* and bail out before loading
anything. Second, check that the modules required
by X occur before X in the sequence.
- The value set in module.desc was never stored for use,
but isn't an attribute of the instance, either. It belongs
with the descriptor, in ModuleManager.
Introduce the notion of emergency modules and emergency jobs.
Initial use will probably center around the preservefiles module,
and possibly umount.
FIXES#928
A potentially emergency module is one that has EMERGENCY
(in CMake) or emergency: true (in module.desc) set.
Any such module must also set emergency: true in the
configuration of the module. This is to allow for
instances of a module that **don't** run as emergency
modules, alongside actual emergency ones.
- Add a TODO for allowing modules to come from somewhere other
than the module loader (this would allow "internal" modules
that are always present)
- Warnings are warnings
- Collect the failed modules, instead of bailing out on the first one
(this also prevents crashes caused by quit() called from a timer).
- Introduce a slot to report on failed module loading (no UI yet).
- Put the (constant) 'Calamares will now quit' on its own debug line.
- Tell the user what the search paths are if a module is not found
(prompted by a mis-configuration in a Neon live image).
- Move type and rename it; put in Calamares namespace
- Emit signals from the viewmanager as results come in
- Remove state changing from welcome view step based on its internal
requirements checking (for now this breaks progressing past the
welcome page)
- Log checking of the requirements
Introduce a method checkRequirements() into the module system so that
individual modules can do their own checking (as opposed to stuffing
it all into the welcome module).
- Was marked incomplete and unused; none of the existing modules
set any requirements, and the descriptors are not set up to
hold the requirements information anyway.
- Dependencies are generally through globalStorage values, or if
there are dependent jobs they should be created in-order by one
source (e.g. though a View or a subclass of CppJob which overrides
jobs() ).
- It is the responsibility of deployers to formulate a settings.conf
that includes all the required modules.
- A 'real' dependency system is going to lead to the introduction
of interface-definitions and a great deal of complexity, for a
use case that can be handled with careful deployment instead.
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.
In order to avoid deep copies, Qt containers over which we iterate must be const
The remaining unported cases require qAsConst (Qt 5.7) or std::as_const (C++17)
