There are currently various different paths to creating a Module (the
internal representation of a module from the rc-file). Depending on how
the Module is created you might get different options set for the Module
since the options are only available near the beginning (and are spread
across many different variables).
Consolidate some of this; this also has the side benefit of making
ksb::Application less of a dumping ground, and let's us get rid of a
'module-option-fixing callback' that needed to be used with a separate
'module-creating-by-name' callback.
Additionally this means that modules take only the options of the
module-set they were actually declared in, instead of the module-set in
use when the module was found (which may be different when using
--include-dependencies).
BUG:345192
FIXED-IN:15.05
Remove the special-case check on kf5umbrella by supporting all
virtual/misspelled dependencies in dependency-data without raising fatal
errors. --verbose still warns about missing dependencies (even with
kf5umbrella) and the worst case is that we try to build modules out of
order until someone notices the metadata is wrong.
That's a much better worst case than that of a couple of days ago
("kdesrc-build won't even start").
BUG:344814
These are usually stripped out later by the dependency analyzer but this
can't help the correctness of the code (e.g. with option handling, which
depends on there being only one right Module to apply options to).
The ->isa() checks still work for superclasses, and knowing that a given
module originally came from a kde-project module set is useful in the
code. In fact this should be considered a regression from the module-set
parse refactoring patch.
This is unfortunately a giant change, as all of the functionality that
is encompassed into module-sets currently had to migrate over to
multiple separate classes, including the new ksb::ModuleSet class and
subclasses.
This was a long-overdue change, however, and should allow for accurately
tracking a source module-set for a given module.
On the other hand this migration of logic has made it easier to
understand each of the individual pieces where they stand (e.g. there is
no longer a separate expandXMLModules and expandModuleSets).
In addition we can properly handle ignore-modules with wildcards just as
we do with use-modules (they even use the same matching logic) which
means that it is safe to integrate this into master (assuming no extra
boogs get added, of course).
This will also help with fixing some of the extant module-selection bugs
(321883, 299415).
BUG:321275
CCBUG:321667
Michael Pyne
David Faure
Martin Klapetek