In other words, we separate parsing of options blocks from whether
existing modules or module-sets have already been seen. Instead we
decide later (when expanding module-sets or modules) whether there are
any relevant options blocks to apply (this is the 'deferred option'
handling).
Now you should be able to declare options blocks that contain options
appropriate for module-sets, even if no module-set is defined with that
name (e.g. if you're doing weirdness with 'include' declarations).
This does require that you don't use the same name for modules and for
module-sets, but that is essentially already a requirement anyways.
There's no good way to always disambiguate that.
BUG:366594
FIXED-IN:16.10
This is intended to split off idea of reading cmdline options to apply
from the idea of reading 'options' blocks to later apply. Right now the
processing for both are intermingled.
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.
This change tries to ensure that modules and module-sets do not have the
same names.
However this doesn't quite work yet -- an option block for a module-set
must meet all requirements for module-sets, including repository
declaration, use-modules, etc. A subsequent patch will refactor that to
fix.
When a configure.ac or configure.in file exists in the source
dir but no configure file and an autogen.sh script exists this
will now run ./autogen.sh in the source dir to hopefully
create the configure file and then use that in the actual configure
step.
This is required for all GnuPG Libraries and so also for GPGME.
REVIEW: 129070
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 makes it more convenient to work with baseline configurations (that
are 'include'd) without changing the upstream configuration.
Still to do: add a warning when modules and module-sets end up sharing
the same name somehow.
BUG:365813
FIXED-IN:16.08
Before:
"Don't use module libaccounts-qt on line 20 of /path/kdesrc-buildrc, use options libaccounts-qt"
but line 20 is unrelated, some global option.
After:
"Don't use module libaccounts-qt on line 20 of /path/extragear/utils/kdesrc-build/kf5-workspace-build-include, use options libaccounts-qt"
REVIEW: 127910
This still takes too long for most shell shortcuts, but will make it
possible to do things like setup shell functions to cd right to a build
dir based only on a module name, check for which git branch a module is
resolved to, or see what config file options a module ended up falling
under.
As part of the documentation changes, I also ported the docs to KF5.
JSON::PP is included in core Perl so one less dependency to look after,
and it's fast enough (for what we need) that there's really no point to
making it possible to look for JSON::XS.
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.
The docs have been at docs.kde.org for a long time, now they're the one
and only recommended location. But I forgot to update the URLs
referenced by the script itself. :(
BUG:357162
FIXED-IN:16.01
As opposed to only kde-projects modules also present in the rc-file.
E.g. this rc-file
---
global
branch-group kf5-qt5
end global
module-set
repository kde-projects
use-modules plasma-desktop
include-dependencies true
end module-set
---
...still lists 83 modules to build if you run kdesrc-build.
We also needed to ensure that each module generated by user selectors
knows to propagate the 'needs dependencies' flag.
Commit 480f184 added a reference to the calligra module to get
lxr.kde.org to make calligra symbols available. However this also pulled
in other modules since kdesrc-build will normally take each entry in
use-modules as a virtual project path to dereference. For instance this
makes it possible to get all KDevelop-related modules by declaring
"use-modules kdevelop".
When this syntax is ambiguous (as it is for kdevelop and phonon) you
could normally do what you wanted by being more specific, using
declarations like "kdevelop/kdevelop" or "phonon/phonon".
However calligra.git is a top-level entry in the virtual project
hierarchy, so something like "/calligra" would still match calligra.git
(at /calligra) and krita (at /calligra/krita).
So, add Yet Another Syntax to allow for specifying a specific git
module while still taking advantage of the special kde-projects
niceties for module-sets. If you specify "foo.git" in a use-modules
entry, kdesrc-build will treat the module as if you'd asked for "foo",
but will not try to do any further searching for other modules in the
virtual project hierarchy.
CCMAIL:faure@kde.org
Now we describe up-to-date module progress (if multiple modules are
being built) and consolidate muliple lines of information into just a
couple (for build and install).
This option can be used to setup the user.name and user.email git-config
options within each new git repository cloned or installed from
snapshot, including kde-projects repositories. This can be useful for
KDE developers with multiple Git identities that they use for
development.
Module settings override global settings so you could e.g. have a global
git-user option for KDE modules and then override specific modules or
module-sets with a different git-user setting.
This setting is only applied during the initial git-clone process
though... if there's interest in having kdesrc-build re-apply settings
later that's possible too.
BUG:352478
FIXED-IN:15.09
The chomp doesn't return the chomp'ed value (rather '1' to reflect
number of characters removed), and fixing that revealed another bug with
my recent change to this code where I forgot to `tee' debug output to
the tty.
Should be a bit faster, but major goal here was to decouple the progress
output from the details of what we're outputting to. Functionality is
still the same (except that ninja progress output now works too) but now
it's that much easier to permit additional means of progress updates in
the future (e.g. a GUI, web server, even a Plasmoid).
When the initrepo script fails the extracted snapshot directory (the
srcdir) is deleted, but it's also the current working directory, which
breaks git when doing the fallback clone. Fix by switching to an
existing directory.
CCMAIL:faure@kde.org
Michael Pyne
Andre Heinecke
David Faure
Jeremy Whiting