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
kde-qt has become qt-kde, and moved from gitorious.org to git.kde.org.
This updates the locations in the kdesrc-buildrc-sample and the built-in
configuration.
The -qt-gif flag was removed from Qt in commit
dfe9084344d73d59f4569c8be6104ce83ae0df95, but it's apparently assumed anyways so the
effect is still the same.
Thanks to Maurel for the report.
BUG:262076
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc-sample; revision=1213033
kdepepo tells me that the submodules /do/ require some of the special
variables from their supermodule (which makes sense). Turns out I
built-in a way a long time ago to force CMake to run when needed, so let's
just go that route.
This should hopefully complete the support needed for strigi for good until
kdesrc-build uses the projects.xml that is under development.
BUG:261638
CCMAIL:cgiboudeaux@gmail.com
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc-sample; revision=1210660
Right now that means just grouping the modules into their own module set, and leaving
out the strigi supermodule.
At some point I may allow module-sets to have their own names so that you can do
"kdesrc-build strigi" from the command line, but for now this will have to work.
BUG:261638
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc-sample; revision=1210570
Michael Pyne
Eike Hein
David Faure
Raphael Kubo da Costa
Raphael Kubo da Costa
Pino Toscano
Raphael Kubo da Costa
Anne-Marie Mahfouf
Montel Laurent
Matthias Fuchs