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.
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.
This makes it safe for things like extragear software to simply
generically depend on kf5umbrella and have kdesrc-build do the right
thing.
Fixes bug 331940, though I know dfaure mentioned it at some point as
well.
FIXED-IN:1.16
BUG:331940
With --verbose kdesrc-build will add a description of what dependencies
it thought each module had to the build output for that module.
With --debug the "Visiting module foo" entries will be arranged
hierarchically in accordance with the tree dependency structure.
Now the priority order for all of the various "I want to checkout this
commit" options are centralized in one spot, and both cloning and
updating obey the same options now (they didn't before).
The most noticeable effect is probably that it should be damn near
impossible not to have automoc build first now, at least in comparison
to other kde-projects modules. It also should take care of the vast
majority of the code needed for bug 312324. Still needed is handling for
Qt/Qt5.
BUG:312324
FIXED-IN:1.16
We now read in and should be able to handle branch-specific dependencies
and module dependency exclusions.
For full support we still need to find a way to properly handle Qt vs.
Qt5 modules (e.g. for phonon Five and automoc).
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).
This was the last remaining module embedded into the main script file,
so if we leave it here this completes the transition of modules out of
the main script.
Michael Pyne
Raphael Kubo da Costa