Even without include-dependencies, without this visit guard the tree
traversal code will add a ksb::Module dependency (when they are
encountered) to the build list every time it is encountered, not just
the first time it's encountered.
Currently it (probably) doesn't support pulling in options for these
modules from their host module-sets (although using 'options' sections
might actually work). I think it ignores the 'ignore-modules' option as
well.
Other than that, it should do pretty much what it says on the tin,
although I had to implement a few other bug fixes as well to get it to
that point.
I want to say that there was an open bug for this but I can't seem to
find it now.
Source items can never be catch-all/wildcard items, so we must
canonicalize these too to prevent e.g. extra-cmake-modules from
depending on kdesupport/extra-cmake-modules due to a '*:
kdesupport/extra-cmake-modules' rule.
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.
This is somewhat confusing; since modules are listed in build order,
indented modules show up *before* the modules that require them.
Essentially, the module that caused an indented module to show up in its
position in the build is the next module in the build that is more
outdented.
Additionally, this only indents in situations where a module's build
order had to be rearranged. Modules that were already in the right order
are not specially indented even if a valid dependency exists.
With all that said, this can be a useful way of determining why
kdesrc-build thinks a given order is required without having to go the
route of a complicated ASCII DAG renderer.
This feature had been intended for cases where a module kde/foo was a
git repository while also being a base for other git repositories
kde/foo/bar, kde/foo/baz, etc. For instance, kde/kdelibs is a git
repository that also held sub-children like kde/kdelibs/kactivities.
However this is fairly rare in KDE repositories now, and this feature in
its easiest-to-implement form has always had to navigate around several
corner cases, so it's better just to explicitly specify dependencies.
This change also prefers the use of short module names. Additionally the
'inherent module dependencies' feature would likely be removed, although
I'm commiting the ported version here in case we'd ever need to bring it
back.
Fixes bug 342806, where a kdesrc-build user notes that "Cloning"
messages are indented while "Updating" messages are not, which can be
confusing.
BUG:342806
FIXED-IN:1.16
Montel Laurent
Michael Pyne
Vishesh Handa
Jeremy Whiting
Milian Wolff
David Faure
Bhushan Shah
David Edmundson