[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: Building RKWard on Mac (continued from private discussion)
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2017-06-08 10:10:43
Message-ID: 12398496.d9Je9KeGBe () portia ! local
[Download RAW message or body]

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é


[prev in list] [next in list] [prev in thread] [next in thread]