This installs needed KDE-related environment settings without going so
far as to install .xsession support. For that, see
install-session-driver, whose documentation has been fixed to make clear
it's not a default.
This is to allow for reading in "options" blocks that may apply to
module-sets later, even if the needed module-set hasn't been read-in yet
(e.g. if it's contained in a common file meant to be included in some
but not all configurations).
To do this right we need to decouple the actions of reading options and
then later applying them to the various OptionsBase subclasses. This is
a start toward that.
The backend side was broken during the upgrades to git.kde.org and
svn.kde.org so let's just skip needless error messages for our users
until this whole thing blows over.
This has the nice side effect of (finally) making KDEXMLReader free of
per-class global state (I keep forgetting Perl supports closures...),
but mostly this is to keep pace with the way we're using the source
repositories and grabbing potentially many dozens of modules at once
from the XML data. Better to just read it once and query rather than
parse anew for each and every set of queries.
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.
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
Right now kdesrc-build will default to kdesrc-buildrc-sample if no
configuration file is present, but that won't be appropriate now that
KF5 is out. Make the user make a choice instead.
The various READMEs and help texts would probably need to be updated to
match, if anyone wants to help. ;)
I was so convinced this was already the case that I told dfaure that was
how the code worked and so it would be hard to find the bug he was
experienced. Whoops.
The corrected code now employs dependency resolution before the
second-pass --resume/--start handling, so that kdesrc-build should still
build modules after their dependencies are built.
This did give me the opportunity to clean up the metadataModule TODO
finally. Now there really is only one place that tracks whether we use
metadata or not, just like it should be.
This is just a rearchitecture, but separates the internal build context
options into:
* flags (true/false settings), can be altered from cmdline.
* varible options, can be altered from cmdline.
* internal options, cannot be altered directly from cmdline.
Adds ignore-kde-structure option which will fetch and compile all
projects in the same dir, meaning that instead of:
extragear/network/kde-telepathy/ktp-text-ui
it would be just
ktp-text-ui
By moving this code and associated utility methods into Application we
nearly complete the long-in-progress refactoring of the monolithic
kdesrc-build script into proper classes/objects.
The kdesrc-build script itself is nearly bare, but there's still a bit
more to do.
At least it should be easier to make individual test scripts to test
different bugs instead of having a monstrosity of a kdesrc-build-test
script that has to maintain a common state.
I've tested this in each way that I'm able (run needing to make a new
source dir, build dir, new install and log dir, run updating existing
checkouts, bzr/svn/git/kde-projects all tested, etc.). But this was a
large move so let me know if I've missed anything.
We need a better name for this feature.
But basically, this allows for creating kde-project repository-wide
"branch groups". For instance, you could list the git branch to use for
the "stable Qt/KDE 4" release/maintenance branch, the "new development
Qt/KDE 4" development branch (typically master, but that has been
changing), and the "upcoming next major release" branch (for us, this
means 'frameworks' sometimes, means 'master' sometimes, other modules
may have different ideas).
By using the 'branch-group' option (which remains to be further
documented) you can say that you want to defer to the metadata about the
repository branches stored in
kde-build-metadata/logical-module-structure. kdesrc-build should even
track branches for you as they are updated by the Release Team, if you
simply want to hang out on stable but compile your own stuff.
Note that this support requires Perl's JSON module (which should come
with Perl 5.14 if I understand it right, but you probably want to
install JSON::XS from CPAN). JSON support is only required for this
feature, it is not a new overall dependency.
See also: http://community.kde.org/Infrastructure/Project_Metadata
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
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.
It's kind of annoying to be unable to build all modules in a certain
kde-projects module grouping, *except* for some certain chosen ones.
Now you can: You can add the ignore-modules option in your module-sets
using kde-projects repository.
It accepts a space-separated list of module names (either kdefoo or
kde/module/kdefoo style) to ignore.
Although the intention is to only filter out matching modules in *that*
module-set, it would actually perform the filtering even if you
accidentally put it in the wrong module set due to a fluke of the
implementation (I recommend not relying on this, however).
The documentation has also been updated, including an example of the
usage.
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).
Michael Pyne
David Faure
Àlex Fiestas