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 previous version worked on modules that had *no* user (a setup most
of mine had as the user was set in the ssh config).
For modules with a user set the trailing '@' was included in the uid
which make the check fail even when the module was correct. (Though I
had thought I had tested this case with other modules).
In the past some KDE SVN modules used the "svn external" feature to pull
in other SVN repositories. These svn-external links were on the *server*
side so the link URL had to use a single scheme.
This scheme was https, which caused quite some problems for anonsvn
users just trying to update from SVN being an unattended kdesrc-build
run, as the SSL cert for svn.kde.org was not signed by a well-known CA.
As a result kdesrc-build updated svn automatically with the expected KDE
SVN SSL signature to avoid blocking on the interactive warning.
This is no longer required. The modules that used svn externals have
pretty much moved onto git now. The new svn server does not even have an
https interface, so this is dead code now, and removed accordingly.
Once I figure out a "preferred" solution for this use case I'll probably
convert to that, until then no reason to pollute with warnings.
I've run a search for other uses of given/when and didn't see any.
Albert Astals Cid fixed dependency-data, Ben Cooksley fixed the module
layout of kde/kde-baseapps* in kde-projects, now to fix the recommended
build order in the samples provided.
The relevant KDE bug for the module moves is Bug 316629.
Should be permanently fixed this time by doing what I should have done
in the first place and making the "needs metadata?" predicate a separate
return value.
Should hopefully be pretty much what it says on the tin. Stop either
right before or right after the given module. (GUI flag since this
involves documentation changes to the Handbook and man page).
BUG:315251
FIXED-IN:1.16
GUI:
applyModuleFilters() would quite happily filter out the metadata module
automatically added to a kde-projects build.
Without the metadata module, later code paths wouldn't know that they
should perform dependency resolution or handle build-script-ignore (as
all 'proj' modules have been expanded to 'git' modules by that point).
BUG:315394
FIXED-IN:1.16
Really I should probably factor out the various 'proj'-creating routines
into a single point of awesome but for now let's just use the old
behavior as a backup in case users give command-line modules...
Commit aa1e4b9542 introduced changes to
how "proj" modules are first parsed (simply keeping the last path
component as entered by the user as the module name).
The unintended side-effect of this is that the user doesn't always have
to enter path ending in an actual repo. E.g. extragear/utils is not a
repo, it would get reduced to "utils", and later KDEXMLReader would
effectively look for all repos matching "*/utils/*".
For more fun, do what I did and try "kdegraphics/libs" => "libs" =>
"*/libs/*"...
Anyways, the fix here is to use the normalized module name as the module
name, but use the full user input for the XML search.
CCBUG:299415
As opposed to reading /all/ output for a given module and only
displaying it immediately before the build phase starts. This makes it
very disconcerting to track git-clone progress...
Though this only works for Git modules, it should at least fix the
annoying "OMG YOUR REPO MOVED" warnings that never get fixed when in
async mode (which is the default).
Previously you simply never saw the warning due to the now-fixed output
squelching, now we need to fix this for good as well.
In synchronous mode it was impossible to get the build subroutine to
attempt to build a module which had no source update, as the updater
code would filter out its build phase *in addition* to marking it as
up-to-date.
This never broke the async code as filtering out the build phase was
always unimplemented (which is what led to a specific IPC type for "code
up-to-date" in the first place).
Michael Pyne
l10n daemon script
David Faure
Montel Laurent
Burkhard Lück
Raphael Kubo da Costa
Yuri Chornoivan