playerstage: update to version 3

[ryandesign (Ryan Carsten Schmidt)]

playerstage-player should be updated to 3.0.0 and playerstage-stage should be updated to 3.2.2.

Both have switched to the cmake build system.

I'm attaching a patch​ containing my attempt to update the ports. Unfortunately playerstage-player fails​ 90% of the way through the build, unable to find boost/signal.hpp. I believe -I${prefix}/include is simply missing from that compile command (though it is clearly there in the earlier compile commands), and I don't know how to add it there. I think it may be an upstream bug.

My patch for playerstage-player changes the python dependency to 2.6 because that's the version it picked up automatically on my system. I don't know how to tell it to use a specific version of python. 2.6 is probably the best version of python 2 to use at this point anyway.

My patch for playerstage-stage is totally untested since it can't be built until playerstage-player is built.

This ticket obsoletes #15932 which requested playerstage-player be updated to 2.1.1.

[ryandesign (Ryan Carsten Schmidt)]

unfinished attempt to update these ports

[ryandesign (Ryan Carsten Schmidt)]

debug output of build failure

[ryandesign (Ryan Carsten Schmidt)]

I got further​: playerstage-player now compiles. I had to patch CMakeLists.txt for three of the utils to tell them where the boost includes are. This is clearly a totally inelegant way to do it but I don't know how things are usually done in cmake land. This problem still needs to be reported upstream.

playerstage-player doesn't seem to be using jpeg or tiff (anymore?). So either we remove those dependencies or maybe something is wrong and it should be finding them but isn't, and if so we should fix that if we can.

playerstage-stage also builds now, with the wrinkle that it now depends on fltk -- but ​fltk doesn't build 64-bit (see also #21054 and #21519). This is a problem primarily on Snow Leopard. In my new patch I force playerstage-stage to build 32-bit as well, but this requires all of its dependencies to be built 32-bit or universal, and there is no MacPorts mechanism to force that to happen; I use the archcheck portgroup to inform the user that they have to rebuild the dependencies.

playerstage-stage still has the problem that its libraries don't use install_name and so can't be used unless you set DYLD_LIBRARY_PATH. The INSTALL.txt even advocates this unfortunate practice. Upstream should fix the software to use install_name properly.

[ryandesign (Ryan Carsten Schmidt)]

revised patch that is mostly complete

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

playerstage-player doesn't seem to be using jpeg or tiff (anymore?). So either we remove those dependencies or maybe something is wrong and it should be finding them but isn't, and if so we should fix that if we can.

I can't find any place where it uses tiff so I removed the dependency.

Multiple emails in the MacPorts mailing list archives show the previous version playerstage-player using jpeg, and the current version still looks for it, but can't find it. ​Someone else noticed that it can't find jpeg anymore (at least in MacPorts) but no solution is suggested there. I commented out the dependency to remind us it should go back in when we can figure out how to do so.

Committed the update in r61643.

[livermouse@…]

Cc Me!