The way kdesrc-build handles letting users type "use-modules frameworks"
and getting everything in frameworks/* back is by implementing the
wildcard search in the KDE XML reader that parses kde_projects.xml. This
uses a two-pass search for simple names, looking for 'name/*' and
'name'.
This results in duplicates, which are normally OK due to other features
in kdesrc-build that prevent duplicate modules from making it into the
build list. However a feature I'm implementing was made much more
difficult by this; easier instead just to prevent finding dups in the
first place.
The last implementation didn't actually match the comments, which was
causing the optimization I committed yesterday to not find some modules
it should have.
I have a fairly large kdesrc-buildrc, and simply doing a
"kdesrc-build --pretend kcalc" (where kcalc is not directly mentioned in
the config file) was taking 32 seconds to complete, since kdesrc-build
would have to go through each possible kde-projects source of kcalc,
and XML-expand it, in order to find kcalc.
Before this fix, each XML-expansion read the whole XML file looking for
modules matching the search string. Then, everything about the XML file
was completely forgotten.
Now the XML file is read only one time, and every possible kde-projects
module is remembered. We then filter the list of modules each time
there's a request. We can probably optimize this still further, but this
alone is enough to get me down to 3-4 seconds locally.
My KF5 installation doesn't show anywhere near as much improvement (but
then it didn't have anywhere near as many different use-modules entries)
so YMMV.
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
Kind of a mouthful, but remove a filter that was added to avoid
automatically including an actual git repository's children that were
also git repositories. E.g. think of something like a SuperBuild git
module that also had its component git modules as logical children
within projects.kde.org.
This filter is unnecessary now that kdesrc-build supports both kde.org
metadata (kde-build-metadata/build-script-ignore) and user-configurable
module filtering (ignore-modules option).
More importantly this filter precludes many other desirable types of
group syntax (e.g. including all of kdebindings just by asking for
kdebindings).
So we remove the filter. The trouble I've seen so far is that it is
now rather difficult to build *only* kdelibs, since kde/kdelibs is a
logical parent of nepomuk-core, nepomuk-widgets, and kactivities. This
can be worked-around by using a normal single module declaration. E.g.
module kdelibs
repository kde:kdelibs
end module
On the other hand, the recently-added config file option
"ignore-modules" should now remove any kde-projects modules that contain
a path component(s) matching the ignored module. You may have to be
specific with a given ignore atom for this reason (e.g. ignore
playground/libs, not 'libs' otherwise you'll also ignore
kdegraphics/libs at this point... though that was also true before this
commit).
BUG:321667
The last commit's first attempt had an error where the kde/foo/* syntax
would be stripped to '*', which the KDEXMLReader actually understands
perfectly. Unfortunately a bare '*' reads in all modules, including
websites and other unpleasant things.
I only caught this by chance, so add a sanity check to make this an
error in case I miss it in the future.
This can be used as a run-time check later to ensure that kdesrc-build
finds compatible versions of its component modules (though that isn't
done yet).
Michael Pyne