Opened 10 years ago

Closed 6 years ago

#45862 closed submission (wontfix)

New port: py-kde4

Reported by: RJVB (René Bertin) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: needs_work Cc: mkae (Marko Käning), chrstphrchvz (Christopher Chavez)
Port:

Description

As mentioned on the ML, I'm trying to make a py-kde4 port. I've made a Portfile based on port:py-qt4's Portfile and at some point that indeed gave me ports py26-pykde4 - py33-pykde4 . Once they were known, I kept tweaking the Portfile so that the port (py33-pykde4) would actually build (meaning I had to undo a number of settings from the Python group).

Somewhere in that process an error must have crept in that now causes the whole python variable to be unknown, reportedly. I haven't been able to tie it to any of the modifications I made after the last successful portindex though. I did *not* do a selfupdate in between (it's been over 2 weeks, I've been working on stuff I wanted to get working before doing upgrades along the way).

So I'm uploading the files "as is", hoping someone will have better eyes than I do.

Attachments (4)

Portfile (3.8 KB) - added by RJVB (René Bertin) 10 years ago.
draft Portfile: needs work
kubuntu-patches.zip (7.8 KB) - added by RJVB (René Bertin) 10 years ago.
relevant patches from the Kubuntu py-kde4 package
pykde4-macports-adaptations.diff (14.0 KB) - added by RJVB (René Bertin) 10 years ago.
pykde4-macports-adaptations2.diff (45.3 KB) - added by RJVB (René Bertin) 10 years ago.

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by RJVB (René Bertin)

Attachment: Portfile added

draft Portfile: needs work

Changed 10 years ago by RJVB (René Bertin)

Attachment: kubuntu-patches.zip added

relevant patches from the Kubuntu py-kde4 package

Changed 10 years ago by RJVB (René Bertin)

Changed 10 years ago by RJVB (René Bertin)

comment:1 Changed 10 years ago by RJVB (René Bertin)

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

To:	macports-users@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@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.

comment:2 Changed 10 years ago by jmroot (Joshua Root)

You don’t need the foreach loop to declare subports, that will be done by the portgroup when python.versions is set. The reason ${python.version} is unset is that you are referencing it from py-pykde4, which is just a stub port and thus has no associated python version. There are a lot of things in this portfile that don’t belong in the stub, and those should be put inside an if statement like this:

if {$subport ne $name} {
    <things that should only be done in the subports>
}

Looks like everything from depends_build to compiler.blacklist (inclusive) should be inside that if statement.

comment:3 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:4 Changed 6 years ago by chrstphrchvz (Christopher Chavez)

I think this was superseded by #47125, which was merged. Can this be closed?

comment:5 Changed 6 years ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:6 Changed 6 years ago by mf2k (Frank Schima)

Resolution: wontfix
Status: newclosed
Version: 2.3.2
Note: See TracTickets for help on using tickets.