Building RKWard on Mac (continued from private discussion)

[René J.V. Bertin]

On Thursday June 08 2017 10:13:35 Thomas Friedrichsmeier wrote:

Hi,


> environment. Maybe that will help create some momentum for
> cross-platform KDE in general.

Let's hope so! In my experience the cross-platform nature is still a bit (too much) considered as a mostly unintentional side-effect of using Qt...

> Because I needed some commits later on that branch.
> https://cgit.kde.org/rkward.git/log/?h=work/frameworks-Mac

Ah, of course, if I'm no longer the only one committing to that branch... :)

I notice this in the commit log:

>    Sigh. clang considers Mac to be case-insensitive, and so will consider
>    
>     rinterface.h the same as Rinterface.h.
>     
>     Further clang and cmake (don't know which is to blame) think it's fun to
>     look
>     for <include.h> in the local dirs, first, then in the system path. Thus,

The first bit is probably a result of you using a case-insensitive filesystem? That, combined with the generally bad idea of distinguishing filenames by their case only can lead to very annoying build issues.
Without a precise log I cannot say exactly what happens, but one has to consider that
1) the underlying system calls like [f]open() will wrap case when opening a file on a case-insensitive HFS filesystem, so it'll open /path/to/foo even if you asked for /paTH/To/fOo. Filename matching will still be case-sensitive though, so depending on how headerfiles are located you'll get failure or the wrong file if case has been changed at some point.
2) directory name case will reflect the case used during the last time the directory was (re)created. IOW, when unpacking a archive containing /path/to/foo.h and /path/To/Foo you will end up with files Foo and foo.h in a directory called either "To" or "to" depending on which was unpacked last (or rather the order in which the unarchiver did the `mkdir -p` to ensure the target directories exist).

The other issue sounds like a cmake issue interacting with the case issue. CMake is powerful, but in the KF5 buildsystem it generates command lines that I think are getting (way) too long and complex.

> For the record, I already had kf5-breeze-icons installed. Adding this
> did not change anything.
>   kiconfinder5 edit-find
> returns nothing.

Just installing Breeze won't do anything of course when another theme is the default, and until now I've avoided adding Breeze to the default theme inheritance as it looks more out of place on Mac than Oxygen.

But I misinformed you. Qt5-kde did indeed set the icon path with an earlier version of the "QSP patch" that was activated at runtime. I removed that patch when the QSP patch was modified to be activated at build time (there were good reasons for that): when you add an icon theme search path, even "pure Qt" applications using the native Mac style get icons on buttons all of a sudden. I find that acceptable as a side-effect from installing port:kf5-osx-integration but not as a general effect.

Could you try `env QT_QPA_PLATFORMTHEME=kde kiconfinder5 edit-find`? You may have to create a ~/.config/kdeglobals file with the appropriate variables set to make that work.

> > Yes, icon-from-theme lookups fail silently and just return an empty
> > icon.
> 
> Hm, not very useful, if you ask me, but I suppose that's Qt's fault?

What else would you have it do? You can specify the fallback result as a 2nd argument to the lookup method.

> Pretty trivial git failure, it would seem:
> https://paste.kde.org/ph9eiipvq

AAAARGHHH, completely forgot to update the URL after the project was moved...
Better late than never I guess :)

> I have no actual idea on the technicalities, but somehow I fail to
> imagine what technical issues could totally prevent the ports to be
> merged.

It's not feasible. mcalhoun's qt5 ports are organised as subports for each Qt component, while my port installs the equivalent of Qt 5.3 minus QtWebkit as a single subport, with QtWebkit, QtWebEngine and its derivatives as subports and stubs for all the other subports. Then, we don't use the same installation layout; mine follows how things are installed in a standard Unix install while mcalhoun puts all into a $prefix/libexec/qt5 (which I only use for the binary stuff that could conflict with Qt4).

Of course the ports could be merged, but we'd end up with a Portfile containing 2 huge sections. That's too cumbersome and risky. As I said, 2 captains on a ship, and one of them (me) doesn't even have commit rights.

> Is this more of an "I don't believe your patches are
> needed"-kind of problem?

No, though there is a "you've made too many changes and I just don't want to spend time testing them all and I don't trust your testing". The qt5 maintainer is of the type who goes MIA from time to time, and then all of a sudden starts changing things. Over 2 years ago I set out doing the necessary work to make the Qt4 and Qt5 ports co-installable with minimal changes because neither of their maintainers had the time (or was MIA, see above...). Evidently my versions evolved because  I couldn't commit the concurrency changes and then at some point, months later, mcalhoun woke up, first took my changes to push a messed-up version (IIRC) and then just put everything in its own prefix. I still regret not having pushed for a maintainership transfer when he was MIA, that would have made things a lot easier for us.
> 
> Just asking, because having two mutually exclusive qt5 ports does not
> seem like a terribly elegant solution to me, in the long run...

Nope, but there could be some justification in the idea of having a mostly stock version that also installs more like how Qt's own installer installs things, and a port that installs a "linuxified" version. I'm also not disappointed that I don't get to do the maintenance of the Qt 5.6 LTS port and legacy ports for older OS X versions (beyond the "hidden" legacy variant installing Qt 5.3.2 on 10.6, and apparently the patching required to build the upcoming Qt 5.9 on OS X 10.9). 

Cheers,
René