[MacPorts] #45862: New port: py-kde4

[MacPorts]

#45862: New port: py-kde4
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.3.2
Resolution:               |   Keywords:  needs_work
      Port:               |
--------------------------+--------------------------------

Comment (by rjvbertin@…):

 Here's an extract of the last important progress messages on the ML:

 {{{
 To:     macports-users at lists.macosforge.org
 Date:   20141110 11:31

 >dependencies to X11. These repeated paths also surely ring a bell. I
 >don't think I ever got around them, but did not try that hard either.


 >> The path shown above seems to have unnecessarily repeated bits. Do you
 perhaps have some kind of recursive symlink problem going on? What is
 causing the very long names in the build/CMakeFiles directory? Surely it's
 pykde4's build system that's responsible for anything happening in there.
 Or

 Yes, I'm now certain that it's pykde4's build system that's responsible,
 but I don't understand how or even where it happens. Part of the issue is
 that that build system does link resolution itself, so you cannot easily
 get around the problem by using a symlink.
 For now I've been able to get around them by tweaking the Portfile to use
 a build directory in /tmp . I'd have preferred to use $TMPDIR but that
 would also resolve to a long path.

 As to the X11 dependencies: that one took a lot of patience too, but I
 managed to put all of those in conditional code blocks (for which sip has
 very limited support so that featured duplicating huge blocks of code) and
 got to the point where it all links.
 It was midnight when I discovered that using the Python PortGroup also
 redefines the commands for the destroot phase, so I called it a night
 before I could do some actual testing.

 NB: even when using the python PortGroup I had to point the CMake system
 to all the necessary python paths; just specifying the python executable
 wasn't enough. Using just that, cmake found Python frameworks of my own
 (/Library/Frameworks/Python33.framework to be exact). I actually had to
 the PYTHON_LIBRARY to the
 Python.framework/Versions/${python.branch}/Python because
 `-F/opt/local/Libray/Frameworks -framework Python` isn't specific enough.
 }}}

 {{{
 To:     macports-users at lists.macosforge.org
 Date:   20141110 22:06

 I've gotten a bit further. Stuff installs, but apparently MacPorts' python
 doesn't look in /opt/local/lib/pythonX/site-packages so I'll have to
 figure out why things get installed there.

 Also, I'll have to figure out how to convince the build system that in
 this case we do need shared objects with .so and not .dylib as extension
 ...

 Suggestions appreciated.
 }}}

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