Add and document the --include-dependencies option. Useful with
--print-modules as a quick way to determine what dependencies a given
module on the command line has, especially if you do a quick
"kdesrc-build --metadata-only" first.
Also, make selecting modules on the command line override
"include-dependencies" as an rc file option, since otherwise it's
impossible to ask just to build a single module if that module is in a
module set with included dependencies.
Use the newly-added --include-dependencies option to force dependency
resolution to happen even if you specify modules to build on the command
line.
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.
I hadn't meant for this to be active by default, but feel free to
uncomment in your own file, or use this as an example of how to generate
your own .kdesrc-buildrc
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.
This is a 2-part change:
1. Always download needed metadata, even in --pretend mode. This means
that even --pretend won't stop kdesrc-build from trying to hit the
network, but --pretend was always intended to let you test command lines
to ensure you got the right build list before you wasted hours trying to
build something. If you don't want kdesrc-build to touch the network
ever, don't run it. :)
2. Check for JSON decoding errors specifically (since it may happen that
the JSON is corrupted on download somehow, or accidentally broken
upstream).
This should allow "kdesrc-build -p --print-modules", or even
"kdesrc-build -p" to work even as the very first command ever run.
BUG:340481
FIXED-IN:1.16
E.g. Running "kdesrc-build kdeedu" with a kdesrc-buildrc containing
module-set
repository kde-projects
use-modules kdeedu
end module-set
would give a runtime exception, even though kdeedu expands to a valid
set of modules. The code here is too restrictive, looking for actual
specific *modules* (i.e. assuming that the use-modules entry specifies a
specific module instead of an implicit wildcard entry).
BUG:339965
FIXED-IN:1.16
There seems to be nothing better than checking for the existence of
files or directories under .git at this point (though it's possible to
decode git-status --porcelain output without too much trouble in the
case of in-progress merges).
This should hopefully help avoid kdesrc-build trying to update a module
that is being worked on.
BUG:334324
FIXED-IN:1.16
Bug 341159 complains about kdesrc-build-setup not setting up the kde:
git prefix, but kdesrc-build-setup itself never even calls git, it just
creates a .kdesrc-buildrc and exits.
However the currently recommended way to start out kdesrc-build is to
run "kdesrc-build --metadata-only" for the first build to setup
directories and download required data, while still letting a subsequent
"kdesrc-build --pretend" do something useful. kdesrc-build didn't setup
the kde: prefix in time to support --metadata-only, and I'm willing to
bet that's what the user was encountering here.
So, setup the git configuration before the first time we can use git.
BUG:341159
FIXED-IN:1.16
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
Michael Pyne
Ben Cooksley
David Edmundson
Montel Laurent
Vishesh Handa
Jeremy Whiting
Milian Wolff
David Faure