Kirigami is now needed to run discover, so it should be build
Purpose is needed by at least kamoso.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Though I admit that I don't yet fully understand why the bug was
present, this seems to fix the use of options like --src-only. There was
an actual bug here: command line options are supposed to override
rc-file options by default, so the call to update the global context
object's options had to happen after the rc-file options were read.
Whatever *this* the problem was, it appears to have been related to
either the generation of the list of potential modules, or the filtering
of that list aftewards.
If other problems are encountered please reopen.
BUG:370534
FIXED-IN:16.11
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
This is really userfull and needed for the plugins on gwenview.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Reviewed at https://git.reviewboard.kde.org/r/128543/
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
adapt header to doctools.git / src / templates
fix wrong + outdated links
use new repo address scheme
set date to 16.05
use http://code.qt.io/cgit/qt/ for Qt repo
add some fixme's where the docbook seems to be wrong or outdated
REVIEW:127820
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
Tomaz Canabrava
David Faure
Daniel Vrátil
Michael Pyne
Andre Heinecke
Tomaz Canabrava
Burkhard Lück
Montel Laurent