The warning here complains about conditions which are already pretty
much fixed from outside of the kdesrc-build user population anyways.
It's still something notable so instead of removing completely I
downgrade it to a debugging message.
BUG:388657
FIXED-IN:18.02
The recent(-ish) switch to allow short name from a few months ago in the
dependency-data files was buggy in the way it handles "catch all"
dependencies.
Dependency information was already shortened down to just the module
name when it was compared against the wildcard dependency rules, which
made it impossible for most of the rules to match (e.g. a dependency for
kde/kdemultimedia/* wouldn't match against 'juk' anymore because at that
portion of the code it's not clear that juk is actually a part of that
set).
I will still have to make some other fixes to permit wildcarded
dependencies to work through indirect modules. E.g. a dependency exists
for kde/foo/bar/bar* to "first-module". A second module depends on
"bar-intermedia-module", which is really under kde/foo/bar/. If
"bar-intermedia-module" is actually being built this is not an issue as
the dependency resolver can read the full path to detect the recursive
dependency onto "first-module". But if "bar-intermedia-module" is not
being built then there's no way to tell that there's really a dependency
on "first-module" since the wildcard dependency would not match.
Since now it may be possible to be searching for dependencies in this
code path even without having found a specific Module, we should pass
along the dependency name we're searching for so our recursive visitor.
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
So now I remember why kdesrc-build didn't recursively include
dependencies.... we took advantage of the fact that dependencies in
kdesrc-build were just for ordering (not for generating the build list)
by using 'kf5umbrella' as a fake module. This allowed workspace modules
to depend on only kf5umbrella instead of all of the frameworks
individually.
The recent changes to support recursive dependencies broke this, but I
wasn't able to reproduce until I introduce a module-set that actually
ran directly across kf5umbrella as a dependency, which is why I didn't
catch earlier.
This is only a workaround for kf5umbrella in particular, but should tide
things over until I can understand and fix it properly. Apologies for
the inconvenience.
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