Building RKWard on Mac (continued from private discussion)

[Thomas Friedrichsmeier]

Hi,

On Thu, 08 Jun 2017 12:10:43 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:
[...]
> 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.

Yes, it's the combination that broke our back, here. Having a header
named "rinterface.h", when also linking against a library that has
"Rinterface.h" has never been a terribly good idea, but not an issue -
not even on Windows - as long as we could rely on "#include <>" looking
in the system path, first (which AFAIU gcc does, but not clang).

> > 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.

Ok, for some reason kiconfinder5 still doesn't find anything (or
doesn't produce any output to the terminal), but starting rkward with
than environment variable does the trick, indeed. Hooray!

(Oh, or maybe not hooray. I just noted that this will also attach the
menubar to the main window, and probably other things that look alien
on Mac).

I must admit I did not quite understand what this means in terms of a
"real" solution. Do I install / depend on kf5-osx-integration, set the
environment variable, or add theme search paths in the code?

> > > 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.

I would have expected to get a null QIcon(), i.e.
  QIcon::fromTheme("nah-thats-wrong").isNull() == true

> > 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.
[...]

Hm, ok, thanks for the explanation.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20170608/8c5660ed/attachment.sig>