The qtdir setting took on much less importance with Qt 5. We've never
officially supported building Qt 5 with kdesrc-build, and qmake and
cmake both use qmake or similar Qt-provided config information to find
Qt, rather than using the unsupported QTDIR environment variable.
As a result, default the value to an empty string (interpreted as use of
system Qt) and stop adding it automatically to the environment variables
defined during the build. If set, it will continue to be used for now.
This also helps the environment setup driver detect when it should look
for the system Qt5 qmake.
Noticed that some of the kf5-*-build-include files use multiple
ignore-modules declarations for a single module set. I like this, it
allows for commenting why the modules are being ignored. But it
shouldn't have worked before. Now it does.
I thought KF5 had removed /apps/ from the DATA_INSTALL_DIR, and so
adjusted the CMakeLists.txt install to match when it turned out my
module search paths were wrong. Turns out /apps/ is used, so put that
path and adjust module search paths instead.
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 permits using path_add when the environment variable already contains
entries with characters that break shell quoting rules.
Technically we'd need to pipe to sed or similar to re-quote single quotes,
hopefully that won't come up...
The kde-env-user stuff is probably extraneous, users who will go through and
tweak the installed kde-env-master.sh script should be skilled enough to
already have their own .bashrc (or equivalent) and be able to setup their own
env vars prior to sourcing kde-env-master.sh
This also ports some of the Qt4/KDE4 stuff to Qt5/KF5, removes now-unnecessary
environment variable settings, etc.
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.
It turns out that there is a code path where ksb::Module objects in the
process of being created do not have ModuleResolver::_applyOptions()
called on them to ensure that deferred options (from "options" blocks in
the config file) as applied if necessary.
This affected modules like libdbusmenu-qt, which if processed as part of
generating the build list from the config file would *NOT* have
_applyOptions() called (because expandModuleSets only ran this on
ksb::ModuleSets being expanded, and the resolveSingleSelector call that
otherwise would have run applyOptions is only called when modules are
passed as cmdline "selectors").
Fix by pushing _applyOptions to be called for all modules processed
through expandModuleSets (which despite the name gets a cut at every
module in the module list), and removing applyOptions from
resolveSingleSelector since it's redundant now.
BUG:382172
FIXED-IN:17.08
Basically, modules which are updated by default but not actually built
(e.g. due to using the manual-build option) are never mentioned in the
kdesrc-build output in the default async mode of operation.
This required a bit of refactoring of the IPC code to fix, since the
underlying cause is that the output during async mode is driven by the
needs of the build thread, which would request updates from the monitor
thread on a per-module basis. But the build thread never inquired about
modules only being updated, so any such modules were never mentioned on
the command line.
purpose is in playground/libs. Apparently it's needed by kamoso, so it should be moved to extragear/libs and added to kf5-extragear-build-include. Follow the review process for this to happen.
kirigami is in extragear/libs. If it's required by discover, it should be moved to kde/workspace, and then it can be added in kf5-workspace-build-include.
If it's also needed by applications, then it needs to be turned into a proper framework....
REVIEW: 129117
CCMAIL: yurchor@ukr.net, aleixpol@kde.org, notmart@gmail.com
Leap 42.2 only has libgpg-error0-1.13-4.19.x86_64, while gpgme master requires
libgpg-error >= 1.17.
Compiling all this stuff also required installing more recent versions of
gettext, automake and autoconf than Leap 42.2 provides, using devel:tools:building.
I'm afraid that gpgme master will soon need more recent version of other things too
(e.g. gnupg), as things evolve, so I hope we can quickly switch to a stable
branch or release tag of gpgme instead, rather than following master.
CCMAIL: aheinecke@intevation.de
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.
Michael Pyne
Eike Hein
David Faure
Luigi Toscano
Allen Winter
l10n daemon script
Tomaz Canabrava
Daniel Vrátil