[MacPorts] #22642: playerstage: update to version 3

[MacPorts]

#22642: playerstage: update to version 3
-------------------------------------+--------------------------------------
 Reporter:  ryandesign@…             |       Owner:  vincent@…                            
     Type:  update                   |      Status:  new                                  
 Priority:  Normal                   |   Milestone:                                       
Component:  ports                    |     Version:                                       
 Keywords:                           |        Port:  playerstage-player, playerstage-stage
-------------------------------------+--------------------------------------

Old description:

> 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 [attachment:playerstage.diff a patch] containing my attempt
> to update the ports. Unfortunately [attachment:playerstage.txt.bz2
> 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.

New description:

 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 [attachment:playerstage.diff a patch] containing my attempt
 to update the ports. Unfortunately [attachment:playerstage-player.txt.bz2
 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.

--

Comment(by ryandesign@…):

 [attachment:playerstage2.diff 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 [http://www.fltk.org/str.php?L2221 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.

-- 
Ticket URL: <http://trac.macports.org/ticket/22642#comment:1>
MacPorts <http://www.macports.org/>
Ports system for Mac OS