[KDE/Mac] No luck with building KF5/Frameworks

[Ian Wadham]

Hi guys,

I have been trying for a week or two to build KF5/Frameworks using the recipe
Jeremy sent me early in February, but with no success.

The email Jeremy sent back then is appended and copies of his two files
are in the attached tarball (they were his profile and kdesrc-buildrc).

What have I tried?  At first I edited Jeremy's files to suit my setup and set the path
to point to René's qt5-mac-devel port, which is installed in my MacPorts, but
no luck with that.  The score was 23 successful builds and 49 failures in
Frameworks alone.  In particular libdbusmenu-qt and polkit-qt-1 failed to build,
which seemed rather serious, because they come very early in the build.

Q1. What do libdbusmenu-qt and polkit-qt-1 do?  They are not mentioned in
        http://api.kde.org/frameworks-api/frameworks5-apidocs/.

So I went back to square one, cleared out all files and directories below my 
devel area (/kdedev/kf5) and followed https://community.kde.org/Frameworks/Building
step by step to re-build everything, including downloading and building Qt5.4
in /kdedev/kf5/qt5 and pointing my kdesrc-buildrc file to that copy of Qt 5.  I used
Jeremy's settings for Qt config, CMake, etc., but found I had to add -force-pkg-config
to the Qt config.  My setup is in the 4 files called my-* in the attached tarball.

Q2. Was adding -force-pkg-config OK?  It does not seem to have done any harm.

Little improvement.  Still the same problems with libdbusmenu-qt and polkit-qt-1.
Then I had a hunch.  On examining all the cmake and build logs carefully, I found
that occasionally a Qt4 header from MacPorts was getting into the act, even though
I was pointing kdesrc-build at <my-prefix>/qt5/qtbase.

So I ran "sudo port deactivate" on qt4-mac and all of its direct and indirect dependents,
which is to say a large part of the software I use day-to-day, including kmymoney4
(vital for my finances).  Then libdbusmenu-qt and polkit-qt-1built and installed OK,
but since then I have had to deactivate and activate all my KDE4/Qt4 stuff every time
I want to try building KF5/Frameworks.

Q3. Is there an error in the Frameworks build setup that allows the Qt 4 headers to
       "leak in" from /opt/local/include?

Q4. Is there some way I can avoid having to deactivate all my regular KDE4/Qt4
       software?  I am not at all comfortable doing that… :-( … my tax return is due.

The next hurdle the build fell at was kcoreaddons (log included in the attached tarball).
The error was when building tests.  Jeremy's settings and mine contain a CMake option
for -DBUILD_TESTING=FALSE, but this is overridden by -DBUILD_TESTING=TRUE in
extragear/utils/kdesrc-build/kf5-frameworks-build-include.  After patching that to
-DBUILD_TESTING=FALSE, kcoreaddons built OK.

Q5. We SHOULD be able to build with -DBUILD_TESTING=TRUE, shouldn't we?
       Isn't built-in testing one of the quality mantras of KF5?  What is the problem here?

Then the build fell at kio, on which a lot of other things depend.  To understand that
one, see the CMake doco on AUTOMOC:
http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html#prop_tgt:AUTOMOC
http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_AUTOMOC_RELAXED_MODE.html#variable:CMAKE_AUTOMOC_RELAXED_MODE

<module-name>.cpp files from KDE frequently contain #include "<module_name>.moc"
as their last line, but that is now incorrect unless the .cpp file contains some pre-processor
code for Qt's MOC utility.  Normally, the pre-processor code is all in the <module-name>.h
file, but occasionally it is not.  You are supposed to write "#include moc_<module-name>.cpp"
if you want MOC to look in the header file, but AUTOMOC will look there anyway after giving
a warning message.  I was sick of seeing all those warnings, so I set
CMAKE_AUTOMOC_RELAXED_MODE=TRUE, not that it seemed to make much difference.

I had to unset it again to get kio to build.  The culprit was a weird-looking "main program" in
frameworks/kio/src/kcms/kio/main.cpp, which ends with #include "main.moc".  There is NO
main.h file in frameworks/kio/src/kcms/kio, where you would normally expect to see it, and
there are no pre-processor lines in main.cpp.  See kio.build.log in the attached tarball.  In
fact this is not really a main program --- no main() procedure, just a macro that evaluates
to a class declaration and definition AFAICT.  Even when the main.cpp builds, I do not know
where the main.h file is found and whether it is the "right" one for THIS main.cpp.

Q6. Can we get the Frameworks programmers to clean up the "moc" usages?

Q7. In the case of frameworks/kio/src/kcms/kio/main.cpp, where IS the correct main.h?

I found two dependencies in the overall build process that are hidden, i.e. not declared
in kdesrc-build, CMake or https://community.kde.org/Frameworks/Building.

One is Bazaar, yet another source-code control system, that is needed to clone libdbusmenu-qt
source code from its repository, right at the start.  I installed MacPorts' port bzr @2.6.0_0.

Q8. Is that the correct version of Bazaar?  Can it be mentioned in the build instructions
       or kdesrc-build scripts or CMake scripts?

The other is libepoxy, need to build kdeclarative, on which kactivities, plasma-framework
and krunner in turn depend.  I installed MacPorts' port libepoxy @1.2_0.

Q9. Is that the correct version of libepoxy?  Can it be mentioned in the kdesrc-build scripts
       or https://community.kde.org/Frameworks/Building?  Libepoxy on MacPorts has
       dependencies mesa and xorg-xproto, but isn't Frameworks/KF5 supposed to be
       free of X11 and other graphics systems?

Our old friend QSP made a brief appearance in some of my build attempts.  It appears
that the Frameworks/KF5 build installs some files in application data directories, as you
might expect, but then the building of later modules (in the same run) invokes programs
that call QSP to find some of the files installed earlier.  I got around errors by forcing the
install dirs and QSP dirs to "line up", using Jeremy's QSP patch and $XDG_DATA_DIRS.

Q10. Is the Frameworks/KF5 build inherently biased towards an XDG setup or can it
       actually be made to work with "native" QSP on non-Linux platforms?

For some reason, the phonon part of the build requires both the VLC and the GStreamer
backends to be built in Frameworks/KF5.  Phonon succeeds, but both backends fail to
build, in my setup.  One reason is that I have a downloaded VLC installed, not the
MacPorts one.  I am reluctant to change that, because I use VLC for presentations, etc.
And I do not really want to install GStreamer just to please Phonon.

Q11. Any ideas on a workaround for building Phonon?  Do we really need it anyway?

I am left with kactivities and kimageformats failing to build, with diagnostics that are
completely unreadable to me (see logs in the attached tarball).

Plasma-frameworks and krunner fail in CMake because kactivities is not built (see logs).

Finally, networkmanager-qt fails in CMake because there is no Network Manager.

Q12. Do I really need any of the 7 modules that fail to build: phonon backends (2),
       kactivities, plasma-framework, krunner, kimageformats and networkmanager-qt?
       Can I try to build a simple application now?

I am getting awfully sick of trying to build Frameworks… :-(

Cheers, Ian W.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: idw_logs.tar.bz2
Type: application/x-bzip2
Size: 20258 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150322/536363c5/attachment-0001.bin>
-------------- next part --------------


> From: Jeremy Whiting <jpwhiting at kde.org>
> Subject: building qt5.4 and frameworks
> Date: 5 February 2015 1:29:08 PM AEDT
> To: ian Wadham <iandw.au at gmail.com>
> 
> Ian,
> 
> In order to build the frameworks with kdesrc-build I've used the attached .kdesrc-buildrc file in my home folder. I also have cloned qt 5.4 branch (and 5.4 from each submodule) into ~/devel/kde/src/qt5 and build in ~/devel/kde/src/qt5build by running configureqt from my attached .profile cmake and other dependencies are from macports exclusively. Let me know if you want a list of which ports I've installed also. Hmm, had to rename them to get them to show up in the file chooser, incidentally, do you know how I could have made the "hidden" files show up in there? I don't see any option there to do so.
> 
> Hope that helps,
> Jeremy