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.
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
Attica for Qt4 requires being built with -DQT4_BUILD=TRUE on the cmake
command line, otherwise it will use Qt5 if it can find it.
Thanks to Riccardo Bellini for the report.
BUG:329797
FIXED-IN:1.16
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.
Although a module like kde/kdeutils/kcalc will eventually end up with a
$module->name() of "kcalc", the module starts off with whatever the user
typed in for its name in the use-modules declaration.
This makes it difficult to override its options in a later module / end
module declaration (as its documented to do). E.g. the kcalc branch for
the following should be "KDE/4.9".
module-set
repository kde-projects
use-modules kde/kdeutils/kcalc
branch KDE/4.10
end module-set
module kcalc
branch KDE/4.9
end module
*** Important ***: There's no way for kdesrc-build to know when parsing
that the "module foo" is supposed to override a module-set module if it
hasn't seen the foo declared yet. In this example, if you simply did
"use-modules kdeutils" then you may end up with a svn-based kcalc (since
it's a "new" module without a repository declaration).
I'm not sure right now if I'll decide that possibility needs to be
handled as well so I'll leave the bug open. But it should be possible to
override any module-set module that is named with this fix.
CCBUG:299415
This is also fixed now in the KDE build metadata but might as well have
it right here too.
Thanks to Jan Hackel for the report and diagnosis.
BUG:298401
Aurélien Gâteau has informed me that libdbusmenu-qt has shifted
development awhile ago to be hosted on Canonical's Launchpad, which uses
the bzr SCM. He also informed me that the gitorious.org repository which
kdesrc-build had been recommending is no longer maintained, and very
politely requested help with having kdesrc-build support bzr.
On the one hand I really don't think it's necessary at this point to
allow for building bleeding-edge libdbusmenu-qt (I would be surprised if
kdelibs depended on a libdbusmenu-qt that hasn't been packaged for
months).
But on the other hand if it does become necessary we will be ready, and
this fits in well with the idea of building Qt and all of the
"kdesupport"-style libs in between Qt and kdelibs.
Unfortunately this shows I still have further to go in my
refactoring/documentation efforts since I still had to end up
implementing the support. But, it was certainly a much easier job than
it would have been before I had started fixing the codebase. This patch
was coded over no more than probably an hour or so (if that time were
consecutive... ;) and Aurélien tested overnight and after fixing my one
mistake reported that it worked swimmingly.
After installing bzr today I can report this works for myself as well,
and without having to insert "hacks" throughout the code to make it
work.
CCMAIL:aurelien.gateau@canonical.com
Now that we have build system metadata handling available we don't need
to retain that rc-file recommended hack to get strigi to build properly.
There's probably others I could remove as well.
Pretty much what it says in the subject, although it depends at this
point on auto-detecting the proper build system correctly.
If you want to see what build system kdesrc-build thinks is required,
run with --verbose or --debug, and the build system will be displayed
with the module name during the build phase.
I mistakenly said an earlier commit implemented this feature though,
it's actually *this* commit.
CCBUG:265255
If we check out kate before, kde-baseapps will refuse to be checked out,
because the directory will already exist and have stuff inside, which
leads to the error "[...] Please either remove the source directory yourself
and re-run this script [...]".
kdegraphics actually needs it as of this writing since it is marked as
inactive in projects.kde.org. Even if it is made active, kdegraphics's
repo should not be built in conjunction with its logical children's
repos.
Michael Pyne
Raphael Kubo da Costa
Jeremy Whiting
Montel Laurent
David Faure
Eike Hein
Raphael Kubo da Costa
Pino Toscano
Raphael Kubo da Costa