[MacPorts] #49213: libkdeedu & kde4-runtime: qt4-mac upgrade causes problems for some KDE4 ports

[MacPorts]

#49213: libkdeedu & kde4-runtime: qt4-mac upgrade causes problems for some KDE4
ports
-----------------------------------------------+-------------------------
  Reporter:  mk@…                              |      Owner:  rjvbertin@…
      Type:  defect                            |     Status:  new
  Priority:  Normal                            |  Milestone:
 Component:  ports                             |    Version:
Resolution:                                    |   Keywords:
      Port:  qt4-mac, libkdeedu, kde4-runtime  |
-----------------------------------------------+-------------------------

Comment (by rjvbertin@…):

 Do the build bots even work still? They still haven't built the updated
 clang-3.6 and python-xy ports, at least not for OS X 10.9 ...

 Anyway, ${prefix}/share/apps/cmake/modules has never been added explicitly
 to `CMAKE_MODULE_PATH` , at least it's not the case on my system running a
 more delicately concurrent Qt4 (and Qt5).
 I haven't traced what exactly goes on here, but it appears that KDE's
 CMake scripts have internal logic that adds components to the
 `CMAKE_MODULE_PATH`, including `share/apps/cmake/modules`. If those fail
 with Qt's change of install layout it is well possible that
 `FindKDE4Internal.cmake` is expected in a path that is derived from one of
 Qt's install paths, and thus now looked for in
 `${prefix}/libexec/qt/share/apps/cmake/modules`.

 Could you try to have a look what value `KDE4_INSTALL_DIR` has for you?

 This may actually be one of the issues I ran into when I did try the
 simple blunt-force concurrency recipe of putting all of Qt in its own
 prefix (they were certainly KDE related), and it certainly does seem to
 support my argument against such an install layout that MacPort's Qt is
 used by software following Freedesktop/XDG conventions.

 It may be that this particular issue is easy enough to correct by adding a
 component to `CMAKE_MODULE_PATH` in the kde4 PortGroup, but I wouldn't
 advise to do that as it may have side-effects. Looking at KDE's cmake
 script, I see cases where `CMAKE_MODULE_PATH` is modified temporarily, and
 restored to its previous value afterwards.


 (I could have gotten to say "told ya" but this one I actually didn't
 expect =) )

-- 
Ticket URL: <https://trac.macports.org/ticket/49213#comment:2>
MacPorts <https://www.macports.org/>
Ports system for OS X