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.
There's no such thing as kdegraphics super repository. One needs to build it all separately!
This patch gets all kdegraphics apps in the correct order (thanks to bcooskley)
I'd like to switch the kdegraphics example fully over to
projects.kde.org's database, but the kdegraphics supermodule is not
constructed at all yet (I can't even find any git submodules) so
until then just spell out each needed submodule.
It actually still exists (although called DebugFull) but it's probably
better to use the optimized-but-debuggable "Debug" profile as a generic
example, especially since stock CMake is aware of Debug.
Reported by "guy-kde", thanks for the report!
CCMAIL:guy-kde@maurel.de
Nowadays Phonon does not come with any backends built in, so we need to
specify what backend to use.
The two best choices are phonon-vlc and phonon-gstreamer. I've chosen
phonon-gstreamer for the default merely because that's the one that
works on my system.
Thanks to Ghislain MARY for bringing it to my attention.
BUG:263937
Michael Pyne
Montel Laurent
David Faure
Raphael Kubo da Costa
Eike Hein
Raphael Kubo da Costa
Pino Toscano
Raphael Kubo da Costa
Anne-Marie Mahfouf
Matthias Fuchs