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

[Ian Wadham]

Hi Marko,

On 23/03/2015, at 6:40 AM, Marko Käning wrote:
On Sunday March 22 2015 15:32:20 Ian Wadham wrote:
>> 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/.
> 
> Well, polkit-qt-1 is only needed for Linux! My OSX/CI system does NOT build it, since I
> disabled it in [1] for kauth:
> ---
> # KDE Frameworks
> #frameworks/kauth: kdesupport/polkit-qt-1
> ---
> So, no need to try to build it and disable kauth's dependency on it on your end as well!

Thanks for the tip!  This is something to be taken on board in an eventual port
of Frameworks/KF5.

>> but since then I have had to deactivate and activate all my KDE4/Qt4 stuff every time
>> I want to try building KF5/Frameworks.
> 
> This is funny. Cool, you got the two to build... But, as written above, you
> don't need it for KF5 to work on OSX!
> 
> And yes, it's a must to make sure that KF5 doesn't pick up anything from KDE4…

See my replies to René on this point.

>> 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?
> 
> Yes, the OSX/CI system can set it and the testing gets integrated seamlessly.

So why is it failing for me?  See the kcoreaddons log in the tarball attached to my
first message on this thread.

>> Q6. Can we get the Frameworks programmers to clean up the "moc" usages?
> 
> Hmmm, my OSX/CI system didn't need any…

That's because you never used CMAKE_AUTOMOC_RELAXED_MODE=TRUE,
I suppose.  It's what caused the problem for me.

Still and all, it is odd that the main.cpp in frameworks/kio/src/kcms/kio can build when there
is no main.h for MOC to work on…  Is it picking up the main.h in a neighbouring sub-tree?
Is that correct?  Why does it work?  Why is the file called main.cpp when it is not a main()
program?  Makes no sense to me.

>> Q7. In the case of frameworks/kio/src/kcms/kio/main.cpp, where IS the correct main.h?
> 
> No change needed on OSX/CI to make it build.
> 
> 
>> 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.
> 
> Yep, it is a mentioned dependency on our OSX/CI wiki page [2].

Wish I'd thought of looking there… :-(

> BTW, more dependencies can be found in [3].

Noted.

>> Q8. Is that the correct version of Bazaar?  Can it be mentioned in the build instructions
>>       or kdesrc-build scripts or CMake scripts?
> 
> Yes.
> 
>> 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.
> 
> That should be fine, although in [3] I make use of libepoxy-devel from our macports-kde repo [4]!

I think that is what we will have to do in an eventual Frameworks port.

>> 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?
> 
> Yes, it should be, but sooner or later you again run into dependency on some X11 thing.
> With libepoxy-devel I tried to get KF5 again X11-free, though, successfully! :-)
> Yet, when I came to have to install opencv for libkface, all X11 stuff came back for me. :(

Sounds like that is a problem in MacPorts, bringing in excess dependencies.

>> Q11. Any ideas on a workaround for building Phonon?  Do we really need it anyway?
> 
> I'd like to learn what could be done about that as well...
> 
>> Finally, networkmanager-qt fails in CMake because there is no Network Manager.
> 
> I don't build it (yet) on OSX/CI.

Another point to note in an eventual Frameworks port.

>> 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?
> 
> Except the latter I can build all of the above.

Could you make any sense of the logs and error messages in the tarball I sent earlier?

>> I am getting awfully sick of trying to build Frameworks… :-(
> 
> I can imagine, don't give up! ;-)
> But I do think we need to improve the wiki pages for the kdesrc-build…

Maybe I should take some of my questions to kde-core-devel.  We need serious help
to make Frameworks/KF5 into a "reproducible" and "deterministic" port of the standard
required by MacPorts developers (and by me: that's why I can depend on MacPorts).

My guess is that problems exist because CMake is designed to search "high and low"
for components of a build.  This might be fine in the many and varied Linux environments,
where there is usually just one "authoritative" copy of a component (wherever it has been
installed), but not so good in an environment where then can be more than one "authoritative"
copy, as with OS X and MacPorts.  Sometimes it picks up the wrong copy...

Cheers, Ian W.

> [1] http://quickgit.kde.org/?p=clones%2Fwebsites%2Fbuild-kde-org%2Fkaning%2Fmp-osx-ci.git&a=blob&h=501c436603b4aeb80190339dcc74a797ec574954&hb=4673eb2b0e7186b4fc9e79b477e12f9894862d64&f=config%2Fbase%2Fkf5-qt5
> 
> [2] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status#SomemoresoftwaresuppliedbyMacPorts
> 
> [3] http://quickgit.kde.org/?p=clones%2Fwebsites%2Fbuild-kde-org%2Fkaning%2Fmp-osx-ci.git&a=blob&h=38165f9c8e9599438fc5fc04e28f9e485d50e083&hb=4673eb2b0e7186b4fc9e79b477e12f9894862d64&f=ports-list.txt
> 
> [4] http://quickgit.kde.org/?p=macports-kde.git&a=tree&h=d576bbfe995754b2f3f4a6ca9dd445c656b9c87c&hb=8e34c9e5a9190ef1fc33ad1305cffe39c62b19d9&f=dports%2Fgraphics%2Flibepoxy-devel