[KDE/Mac] kdesrc-build

Wed Nov 26 13:39:47 UTC 2014

Thank you all for the warm welcome.

On Wed, Nov 26, 2014 at 2:47 AM, René J.V. <rjvbertin at gmail.com> wrote:

> On Wednesday November 26 2014 14:56:32 Ian Wadham wrote:
>
> Hello Jeremy,
>
> >And welcome to our list.
>
> Plussing that :)
>
> >override the ones that Apple OS X has in /usr. Another problem might be
> that my
> >kdesrc-build setup "borrows" quite a lot of already-built KDE/Qt
> components from
> >MacPorts, including Qt 4 itself, and of course that would not work with
> KF5.
>
> An additional hurdle that we face with MacPorts is that Qt4 and Qt5
> currently cannot be installed in parallel. It's either the one or the
> other. Evidently that doesn't exactly help getting KF5-Mac off the ground,
> and from what I understand it would also make it impossible to support the
> support for KDE4 applications. That is, if KDE4 applications under KF5 use
> Qt4 and not Qt5 (which seems obvious).
>
> We could really need some help in setting up Qt for that. It seems there's
> currently only 1 maintainer for the Qt ports, and he never replied when I
> offered to try and help out. And sadly the Qt4-mac portfile is complicated
> enough to be very dissuasive to get this going myself.
> An additional hurdle for me is that I actually use KDE software in my
> daily stuff, so I can't allow myself to break something - and I'd want
> whatever effort we come up with to move Qt4 into its own corner to be
> complemented by a set of symlink instructions that allow existing Qt4-mac
> apps to function without having to rebuild *everything* (or Qt5-mac apps
> for those who live in that world already).
>

Why are qt4 and qt5 not coinstallable? I'm somewhat new to mac and how it
works, but on linux they are installable into different paths, and the
rpath of the binary helps the loader know which .so file(s) to load. On
windows whatever version is in the path (or next to the binary itself) is
loaded, is there no similar system available on mac ?

>
> >You need also to specifically request the command-line utilities, which
> are no
> >longer bundled with Xcode.
>
> I don't think that's true, not on 10.9+ in any case. In fact, if you
> install the command-line tools plus Xcode you end up with 2 distinct
> compiler toolchains. True to Apple's "we also sell diskspace so we bloat
> our apps to the max", Xcode contains everything in its app bundle;
> compiler, SDKs (even those for iThing development), etc.
>

No worries I got past that, I'm able to build other things with macports
fine and it works.

>
> >> 2. What are the major barriers, technical and/or organizational, that
> prevent newcomers from getting, building, and contributing fixes to kde on
> mac ? I think I remember a link to a wiki of technical issues, but I'm also
> interested in organizational issues. If we can solve some/most of these we
> could get many more hands helping with this work.
>
> There are a few. I already described one above (but that's MacPorts
> specific). The "problem" I see with efforts like MacPorts, Fink, homebrew
> and Gentoo Prefix is that they're aimed at and largely used by people who
> did not "Move to Mac" from MS Windows, but from systems where they used the
> kind of software provided by those efforts (or they used Cygwin on Windows
> :)). In other words, they're probably not representative of the typical Mac
> developer who knows his/er Cocoa and can dream ObjC. And those same people
> are probably very tolerant of the little naggles that FOSS not developed
> specifically for OS X can display, and likely to come up with workarounds
> rather than true solutions.
> At the same time I feel some resistance to certain true solutions, because
> it would require substantial changes in KDE (and sometimes even Qt; see the
> menu issue Ian mentioned). And substantial changes in KDE are very non PC
> (pun intended) at the moment, because of the transition to KF5. And
> because  KF5 is out of reach to us for now, we're a bit in a deadlock.
> Among the substantial changes there would be better support for ObjC(++)
> in the build system, and also in KDevelop which I at least find to be very
> helpful in learning how to write for/with KDE. The KDevelop author(s) won't
> consider anything new for the KDE4 branch which is in some sort of
> life-support. Even a very simple mod that makes the IDE treat ObjC files
> like regular C and ObjC++ like C++ was not accepted. The attitude is less
> polarised elsewhere but the impression is very much that we're late to the
> party and it's up to us to catch up by ourselves. And preferably yesterday.
> Another source of misunderstanding seems to be the very use of Qt. For
> users of Mac and Windows systems, the main reason for choosing Qt for
> development is its cross-platform nature. It seems this is not the case for
> development on Linux, at least I've been told that cross-platform support
> is not the KDE is built atop Qt. Combine that with the catch-up situation
> in which we indeed are, and you get a context in which efforts like moving
> code from KDE4 to Qt5 probably made a number of not-so-happy choices for OS
> X. Marko can probably give you more specific details about the kind of
> obstacle he's been running into in his efforts to get KF5 to build and
> actually function on OS X.
>

Yes, I've discussed some issues with QStandardPaths with Marko already.
What is the policy of macports itself? does it only install everything into
some prefix and have a policy not to touch system paths such as
~/Library/Application
Support/<APPNAME>", "/Library/Application Support/<APPNAME>".
"<APPDIR>/../Resources" which is used for DataLocation and
"~/Library/Application
Support", "/Library/Application Support" which is used for
GenericDataLocation in QStandardPaths?

>
> >> P.S. My main reason for initially setting up a mac vm is to build/run
> applications and fix issues on this platform that don't appear on other
> platforms. CI is interesting to me, but not as much as individual
> developers building, running, and bugfixing on this platform.
>
> Hear hear!
>
> Wait, bugfixing. Here's another little tidbit: debugger support. It's a
> PITA to get gdb to work on recent OS X versions (even I haven't succeeded
> yet), and apparently it doesn't work perfectly even if you get the OS to
> allow it to function. It was certainly problematic enough on OS X 10.6.8
> already.
> In other words, we absolutely need to teach KDE to talk with lldb. While
> that might make it into kdelibs and kde-runtime without too much objection
> (for crash reporting), I doubt it'd make it to KDevelop 4 even if we manage
> to cook up something good enough.
>

Heh, gdb not working well on mac, that's fine by me. I see a similar issue
with debugging on windows. I've resorted to adding qDebug() lines all over
the place to fix issues there, can do likewise on mac, no problem. That
said I am surprised that the patches to kdevelop 4 were rejected. I bet
patches to the frameworks version would be seen with more interest though,
I think kdevelop has been frameworks based for a very long time at least on
it's main development branch (master).

All in all I somewhat understand the feeling you're getting from the kde
community that qt4 based changes are not needed anymore. The
"fun/new/interesting" frameworks based code is where all effort is
currently it seems. Good or bad that's just the state of the current focus
I guess. Personally I think it's a bit of a shame but there are technical
reasons to move on from qt4 to qt5 also as many new features have been
added (many from the old kdelibs4 in fact too). I bet we can get most of
these issues solved and get macports and kde on mac back up to speed though.

At this point I have two questions to get me started/further along:
1. What mac port satisfies the perl json requirement of kdesrc-build? I
tried installing the p5-json-any port, but kdesrc-build doesn't seem to
either see it or accept it as filling it's requirement for json parsing.
2. Why can't qt4 and qt5 be coinstalled on mac as I asked above?

thanks,
Jeremy

>
> Cheers,
> R.
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20141126/80a396a7/attachment.html>