phonon update to 4.8.3, with Qt5 support

[RJVB (René Bertin)]

Attached is an update for port:phonon, bringing it up to date to the current stable version, 4.8.3 .

I've added a subport to build "4Qt5". I haven't gotten the demos to build (qt5-phonon +demos), yet; help from cmake gurus appreciated.

[mf2k (Frank Schima)]

Thanks. The revision line should be deleted because it starts at 0 when increasing the version and that is the default value.

[RJVB (René Bertin)]

The demos build now, and are installed in ${qt_bins_dir}.

Phonon used to be built forcing the compatibility version to 4.4.0 on the generated libraries, for "historical reasons". It seems that that dependency (can) make(s) it into Qt4's libraries if phonon is present when Qt4 is built. Or it's a hard-coded requirement; I have no way of telling at the moment without rebuilding Qt4 which is not an option right now. Hence, building without the patches and thus phonon's default creates libraries with compat. version 4.0.0, which are rejected by dyld. This is not the case for Qt5.

So the new patch introduces a default variant compversion440 for Qt4, which may be removed when Qt4 gets a version bump (4.8.7, or my "concurrent" version is committed). To be continued...

NB: I haven't bumped the revision because this is an unpublished Portfile.

[mkae (Marko Käning)]

Cc Me!

[springermac (Jonathan Springer)]

Cc Me!

[RJVB (René Bertin)]

Aligned the Qt5 subport to using a name suffix, as it seems we settled down on that as a preferred labelling approach.

[RJVB (René Bertin)]

New version removes an implicit dependency on PulseAudio that got pulled in if installed.

[michaelld (Michael Dickens)]

I updated phonon to 4.8.3 in r133625. I did not add support for Qt5. Can you load the latest dports tree & tweak your patch to be Qt5 specific? Do you know if we can have phonon-qt4 and phonon-qt5 installed at the same time by default (without having to use different install prefixes or lots of tweaks to the CMake files)?

[RJVB (René Bertin)]

Replying to michaelld@…:

Can you load the latest dports tree & tweak your patch to be Qt5 specific?

What exactly do you mean by that? A patch against the version you just uploaded that just adds the Qt5 subport?

Did you actually rename the port to phonon-qt4? AFAIK that's not exactly in line with how things are done generally; Linux too seems to keep the implicit version at qt4 (so we'll probably be migrating to a scheme that includes the Qt version starting with qt5).

Do you know if we can have phonon-qt4 and phonon-qt5 installed at the same time by default (without having to use different install prefixes or lots of tweaks to the CMake files)?

You do remember that I've made Qt4 and Qt5 co-installable, right? So, yes, I have both installed, and I also have the VLC backends installed for both (not yet ready for submitting here).

Your question is moot IMHO as long as the co-installable Qt4 and Qt5 portfiles haven't been incorporated officially. The Qt5 subport should build regardless of how Qt is installed so users with an old-style exclusive Qt install will be able to install only the phonon version for their Qt version.

[michaelld (Michael Dickens)]

This issue has 2 or more parts: update to 4.8.3, add support for Qt5, tweak support for Qt4. I addressed the first part, but that means your patch is no longer valid based on the current Portfile. Hence, I'm asking if you want to redo your patch based on the new Portfile. I think we can separate out co-installable Qt4 and Qt5 and just work on making phonon co-installable -- so 2 ports, one for Qt4 and another for Qt5. When co-installabilily is added to Qt4 and Qt5, if we've worked over this port correctly then it will just need a rev-bump to get the change in place. Maybe.

[RJVB (René Bertin)]

Replying to michaelld@…:

I addressed the first part, but that means your patch is no longer valid based on the current Portfile.

I see that. I'm going to need to gather courage to dive back in :(

When co-installabilily is added to Qt4 and Qt5, if we've worked over this port correctly then it will just need a rev-bump to get the change in place. Maybe.

I have no reason to believe that my version was incompatible with the Qt (4 and 5) versions currently in MacPorts. My portfile used macros defined by the Qt PortGroups (either version, before and after my interventions) and didn't make any assumptions concerning the way Qt is installed. The Qt plugins directories where phonon is installed were never exclusive.

[dbevans (David B. Evans)]

Replying to michaelld@…:

I updated phonon to 4.8.3 in r133625. I did not add support for Qt5. Can you load the latest dports tree & tweak your patch to be Qt5 specific? Do you know if we can have phonon-qt4 and phonon-qt5 installed at the same time by default (without having to use different install prefixes or lots of tweaks to the CMake files)?

This morning after upgrading phonon to 4.8.3, I found that digikam and several of its dependencies are broken due to the libphonon version change involved.

Specifically

     digikam @4.0.0 
         /Applications/MacPorts/KDE4/digikam.app/Contents/MacOS/digikam
         /opt/local/lib/kde4/kipiplugin_advancedslideshow.so
         /opt/local/lib/kde4/kipiplugin_gpssync.so
         /opt/local/lib/libdigikamcore.4.0.0.dylib
         /opt/local/lib/libkgeomap.1.0.0.dylib
     kde4-baseapps @4.14.3 
         /Applications/MacPorts/KDE4/dolphin.app/Contents/MacOS/dolphin
         /opt/local/lib/kde4/adblock.so
         /opt/local/lib/kde4/domtreeviewerplugin.so
         /opt/local/lib/kde4/konq_aboutpage.so
         /opt/local/lib/kde4/konq_sound.so
         /opt/local/lib/kde4/konqsidebar_web.so
         /opt/local/lib/kde4/minitoolsplugin.so
         /opt/local/lib/kde4/rellinksplugin.so
         /opt/local/lib/kde4/validatorsplugin.so
         /opt/local/lib/kde4/webarchiverplugin.so
         /opt/local/lib/kde4/webarchivethumbnail.so
         /opt/local/lib/libkdeinit4_dolphin.dylib
     kde4-runtime @4.14.3 
         /Applications/MacPorts/KDE4/khelpcenter.app/Contents/MacOS/khelpcenter
         /Applications/MacPorts/KDE4/knotify4.app/Contents/MacOS/knotify4
         /opt/local/lib/kde4/libkmanpart.so
         /opt/local/lib/libkdeinit4_khelpcenter.dylib
     marble @4.14.3 
         /Applications/MacPorts/KDE4/marble.app/Contents/MacOS/marble
         /opt/local/bin/marble-mobile
         /opt/local/bin/marble-qt
         /opt/local/bin/marble-touch
         /opt/local/lib/kde4/libmarble_part.so
         /opt/local/lib/kde4/marblethumbnail.so
         /opt/local/lib/kde4/plasma_applet_worldclock.so
         /opt/local/lib/kde4/plasma_runner_marble.so
         /opt/local/lib/kde4/plugins/designer/LatLonEditPlugin.so
         /opt/local/lib/kde4/plugins/designer/MarbleNavigatorPlugin.so
         /opt/local/lib/kde4/plugins/designer/MarbleWidgetPlugin.so
         /opt/local/lib/kde4/plugins/marble/AnnotatePlugin.so
         /opt/local/lib/kde4/plugins/marble/AprsPlugin.so
         /opt/local/lib/kde4/plugins/marble/AtmospherePlugin.so
         /opt/local/lib/kde4/plugins/marble/CachePlugin.so
         /opt/local/lib/kde4/plugins/marble/CompassFloatItem.so
         /opt/local/lib/kde4/plugins/marble/CrosshairsPlugin.so
         /opt/local/lib/kde4/plugins/marble/CycleStreetsPlugin.so
         /opt/local/lib/kde4/plugins/marble/EarthquakePlugin.so
         /opt/local/lib/kde4/plugins/marble/EclipsesPlugin.so
         /opt/local/lib/kde4/plugins/marble/ElevationProfileFloatItem.so
         /opt/local/lib/kde4/plugins/marble/ElevationProfileMarker.so
         /opt/local/lib/kde4/plugins/marble/FlightGearPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/FoursquarePlugin.so
         /opt/local/lib/kde4/plugins/marble/GosmoreReverseGeocodingPlugin.so
         /opt/local/lib/kde4/plugins/marble/GosmoreRoutingPlugin.so
         /opt/local/lib/kde4/plugins/marble/GpsInfo.so
         /opt/local/lib/kde4/plugins/marble/GpsbabelPlugin.so
         /opt/local/lib/kde4/plugins/marble/GpsdPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/GpxPlugin.so
         /opt/local/lib/kde4/plugins/marble/GraticulePlugin.so
         /opt/local/lib/kde4/plugins/marble/HostipPlugin.so
         /opt/local/lib/kde4/plugins/marble/JsonPlugin.so
         /opt/local/lib/kde4/plugins/marble/KmlPlugin.so
         /opt/local/lib/kde4/plugins/marble/LatLonPlugin.so
         /opt/local/lib/kde4/plugins/marble/License.so
         /opt/local/lib/kde4/plugins/marble/LocalDatabasePlugin.so
         /opt/local/lib/kde4/plugins/marble/LocalOsmSearchPlugin.so
         /opt/local/lib/kde4/plugins/marble/LogPlugin.so
         /opt/local/lib/kde4/plugins/marble/MapQuestPlugin.so
         /opt/local/lib/kde4/plugins/marble/MapScaleFloatItem.so
         /opt/local/lib/kde4/plugins/marble/MeasureTool.so
         /opt/local/lib/kde4/plugins/marble/MonavPlugin.so
         /opt/local/lib/kde4/plugins/marble/NavigationFloatItem.so
         /opt/local/lib/kde4/plugins/marble/NominatimReverseGeocodingPlugin.so
         /opt/local/lib/kde4/plugins/marble/NominatimSearchPlugin.so
         /opt/local/lib/kde4/plugins/marble/OSRMPlugin.so
         /opt/local/lib/kde4/plugins/marble/OpenCachingComPlugin.so
         /opt/local/lib/kde4/plugins/marble/OpenDesktopPlugin.so
         /opt/local/lib/kde4/plugins/marble/OpenRouteServicePlugin.so
         /opt/local/lib/kde4/plugins/marble/OsmPlugin.so
         /opt/local/lib/kde4/plugins/marble/OverviewMap.so
         /opt/local/lib/kde4/plugins/marble/Photo.so
         /opt/local/lib/kde4/plugins/marble/PlacemarkPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/Pn2Plugin.so
         /opt/local/lib/kde4/plugins/marble/PntPlugin.so
         /opt/local/lib/kde4/plugins/marble/PositionMarker.so
         /opt/local/lib/kde4/plugins/marble/PostalCode.so
         /opt/local/lib/kde4/plugins/marble/ProgressFloatItem.so
         /opt/local/lib/kde4/plugins/marble/RouteSimulationPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/RoutingPlugin.so
         /opt/local/lib/kde4/plugins/marble/RoutinoPlugin.so
         /opt/local/lib/kde4/plugins/marble/SatellitesPlugin.so
         /opt/local/lib/kde4/plugins/marble/Speedometer.so
         /opt/local/lib/kde4/plugins/marble/StarsPlugin.so
         /opt/local/lib/kde4/plugins/marble/SunPlugin.so
         /opt/local/lib/kde4/plugins/marble/Weather.so
         /opt/local/lib/kde4/plugins/marble/Wikipedia.so
         /opt/local/lib/kde4/plugins/marble/YoursPlugin.so
         /opt/local/lib/libmarblewidget.0.19.2.dylib
         /opt/local/share/qt4/imports/org/kde/edu/marble/libMarbleDeclarativePlugin.so
     kdelibs4 @4.14.3 
         /opt/local/lib/kde4/kfileaudiopreview.so
         /opt/local/lib/kde4/khtmlimagepart.so
         /opt/local/lib/kde4/libkhtmlpart.so
         /opt/local/lib/libkhtml.5.14.3.dylib
         /opt/local/lib/libknotifyconfig.4.14.3.dylib
         /opt/local/lib/libplasma.3.0.0.dylib
     kdepimlibs4 @4.14.3 
         /opt/local/lib/libakonadi-calendar.4.14.3.dylib
         /opt/local/lib/libakonadi-contact.4.14.3.dylib

They all give an error similar to the following

Incompatible library version: /opt/local/lib/kde4/khtmlimagepart.so requires version 4.4.0 or later, but /opt/local/lib/libphonon.4.dylib provides version 4.0.0

Reverting to phonon @4.7.2_1 fixed the issue.

So looks like all binary dependents of phonon (those that link with libphonon) need to be revbumped as a result of this upgrade.

[RJVB (René Bertin)]

Well, that's a different thing: Michael apparently forgot to add the compversion440 variant, or to make it a default variant.

[dbevans (David B. Evans)]

They all give an error similar to the following

Incompatible library version: /opt/local/lib/kde4/khtmlimagepart.so requires version 4.4.0 or later, but /opt/local/lib/libphonon.4.dylib provides version 4.0.0

Reverting to phonon @4.7.2_1 fixed the issue.

So looks like all binary dependents of phonon (those that link with libphonon) need to be revbumped as a result of this upgrade.

Worse than that most of them fail to configure with the following error

CMake Error at /opt/local/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Did not find automoc4 (Automoc4Config.cmake, install
  git://anongit.kde.org/automoc).  (missing: AUTOMOC4_EXECUTABLE)
Call Stack (most recent call first):
  /opt/local/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindAutomoc4.cmake:49 (find_package_handle_standard_args)
  cmake/modules/FindKDE4Internal.cmake:428 (find_package)
  CMakeLists.txt:56 (find_package)

automoc is installed

$ port installed automoc
The following ports are currently installed:
  automoc @0.9.88_5 (active)

[michaelld (Michael Dickens)]

I removed the library compatibility patch because, well, it was old and why would anybody need it anyway? So ... now we know why the library compatibility patch was in place. Reinstated in r133635.

[michaelld (Michael Dickens)]

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work (they were located in ${prefix}/lib/cmake, which is non-standard on OSX). ${prefix}/cmake/Modules is a standard install location for "new style" cmake module files. I will try building some of the KDE ports to see what happens for me.

[dbevans (David B. Evans)]

Replying to michaelld@…:

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work (they were located in ${prefix}/lib/cmake, which is non-standard on OSX). ${prefix}/cmake/Modules is a standard install location for "new style" cmake module files. I will try building some of the KDE ports to see what happens for me.

Thanks, I'm not a KDE kind of guy as you can see. By the way, I can confirm that your update to phonon fixed the previous binary linking issue.

[RJVB (René Bertin)]

Replying to michaelld@…:

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work

Maybe because they were/are looked for elsewhere?

When did you move the automoc cmake files? I'm running out-of-date versions on my own system, but I've been able to build quite a few KDE packages on Bradley's VM with my version of the phonon port in place...

[michaelld (Michael Dickens)]

Replying to rjvbertin@…:

Replying to michaelld@…:

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work

Maybe because they were/are looked for elsewhere?

CMake looks for these files in a variety of places. CMAKE_INSTALL_PREFIX/share/cmake* is one of them. Phonon uses them correctly. Maybe it's ports that don't use cmake directly to do configuration but still require cmake for other things (I have no idea what this means; just throwing it out there)?

When did you move the automoc cmake files? I'm running out-of-date versions on my own system, but I've been able to build quite a few KDE packages on Bradley's VM with my version of the phonon port in place...

I did the checkin Friday night (US/ET); r133624.

[michaelld (Michael Dickens)]

Replying to devans@…:

Thanks, I'm not a KDE kind of guy as you can see.

I'm not a KDE user either, but there are plenty of other folks who are & want the various KDE ports to work well on OSX.

By the way, I can confirm that your update to phonon fixed the previous binary linking issue.

Great; thanks! I added a comment into the Portfile with that patch, so that in the future hopefully we'll remember why it's there :)

[RJVB (René Bertin)]

Replying to michaelld@…:

Replying to devans@…:

Thanks, I'm not a KDE kind of guy as you can see.

I'm not a KDE user either, but there are plenty of other folks who are & want the various KDE ports to work well on OSX.

Yes. Please, install a few representative KDE ports and test against those if you modify things that are used by KDE ... We're having issues enough as it is.

Anyway, it seems you pushed a new version that works now?

Great; thanks! I added a comment into the Portfile with that patch, so that in the future hopefully we'll remember why it's there :)

I have a rather distinct memory of having discussed that tweak with someone in a recent past, presumable you, and presumable when I started updating phonon (or Qt, or both).

Maybe because they were/are looked for elsewhere?

CMake looks for these files in a variety of places.

I wasn't thinking of CMake per se, but rather that CMake can be instructed to look elsewhere. Possibly even because the automoc cmake files were installed in a non-standard location (where CMake doesn't look by default, or does it?).

A bit like how the kde4 PortGroup file hardcodes a QCA location that is no longer valid when Qt is installed in "concurrent mode" (not that this particular hardcoding isn't necessary either way...)

[RJVB (René Bertin)]

Replying to michaelld@…:

I removed the library compatibility patch because, well, it was old and why would anybody need it anyway? So ... now we know why the library compatibility patch was in place. Reinstated in r133635.

Note that it's probably unnecessary in itself: I didn't apply it in the Qt5 subport. But removing it forces a rebuild on a potentially enormous amount of ports, some of which are pretty enormous themselves. Which is why that exchange about this "tweak" that I can remember resulted in the conclusion that "it doesn't hurt so we can just as well leave it in for Qt4".

[michaelld (Michael Dickens)]

OK; automoc issue should be fixed in r133636 and r133637. I don't know how it was working before (when the files were installed into "${prefix}/lib/cmake/automoc4/*". The issue was that the Automoc4Config.cmake script tries to find the install ${prefix} by finding the directory that is "../.." from it's current location (in this case, "${prefix}/lib"). It then looks for "automoc4" in the "bin" subdirectory therein, which just won't work. So, I added another ".." to the relative path lookup, which now works for me when configuring kdelibs4.

Phonon doesn't actually use this Automoc4 because newer cmake provides this functionality built-in; it does a "find_package(Automoc4)" only for older CMake, which is why I didn't see this issue before.

[michaelld (Michael Dickens)]

And, r133638. Forgot the patch! I'm getting sloppy in my "advanced" age ...

[RJVB (René Bertin)]

Replying to michaelld@…:

Phonon doesn't actually use this Automoc4 because newer cmake provides this functionality built-in; it does a "find_package(Automoc4)" only for older CMake, which is why I didn't see this issue before.

Which would mean that phonon-backend-vlc (and ~-gstreamer) no longer need to declare automoc as a dependency; they're the only ones I apparently have installed to do that?

[dbevans (David B. Evans)]

Replying to michaelld@…:

And, r133638. Forgot the patch! I'm getting sloppy in my "advanced" age ...

After this commit, the ports that I was having automoc problems with (dependencies of digikam that depend on phonon) now configure and build. In particular,

kdelibs4
kdepimlibs4
kde4-runtime
kde4-baseapps
marble

Thanks for the fix.

[mkae (Marko Käning)]

So, can we commit this then?

[RJVB (René Bertin)]

Replying to mk@…:

So, can we commit this then?

As I already said in PM: no. Unless you want to commit again as soon as I've found the courage to reintroduce the Qt5 subport.

[mkae (Marko Käning)]

I don't know what made me remove michaelld as owner back then.

What's the status of this patch, René? I figure this is not compatible with current qt5-mac, right?

[RJVB (René Bertin)]

The status is that I haven't touched it. I wrote about finding courage 3 months ago, and what really happened is that I got side-tracked (by things requiring courage to start from scratch, not redo what had already been done) and then completely forgot about it...

That said, the Portfile I have should work with both the old and the current qt5-mac, the only thing that I cannot guarantee is how it'll work when you try to install both the Qt4 and the Qt5 versions. Binary builds would probably work, but it's not currently possible to build Qt5 ports with an active qt4-mac present.

I'll see if I remember what and why I did at the time, and then see if I can merge my changes with Michael's Portfile or vice-versa.

[RJVB (René Bertin)]

The unified and side-by-side diffs are much more impressive than what actually had to be done.

Michael's version has removed all calls to install_name_tool that I think the compversion440 variant should make for backward compatibility. I've found it safer to leave them in.

[mkae (Marko Käning)]

Two points I spotted:

• Why did you leave lines 159-163 still in the diff?
• Perhaps there should be a comment why line 78 was commented out?

Question is also how I could test whether this port actually functions as expected.

[RJVB (René Bertin)]

updated against mainstream Portfile r134243

[RJVB (René Bertin)]

Replying to mk@…:

Question is also how I could test whether this port actually functions as expected.

The answer to the more important question is: not now, go take a break! ;)

[mkae (Marko Käning)]

Don't know why, but your diff doesn't apply here on my end:

$ svn log -l 1
------------------------------------------------------------------------
r134243 | michaelld@macports.org | 2015-03-20 15:52:09 +0100 (Fri, 20 Mar 2015) | 2 lines

phonon: use new cmake 1.0 PortGroup feature cmake.out_of_source (ticket #47197).

------------------------------------------------------------------------
$ patch -p0 <phonon-483.diff 
patching file Portfile
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 21.
Hunk #3 FAILED at 95.
Hunk #4 succeeded at 151 with fuzz 1 (offset -12 lines).
3 out of 4 hunks FAILED -- saving rejects to file Portfile.rej

[RJVB (René Bertin)]

Attaching a redone patch based against the r134243 Portfile (with md5 sum 362a8033383f760540572a18a38ec0fb)

[RJVB (René Bertin)]

Cc Me!

[mkae (Marko Käning)]

This is what I get with current qt5-mac installed:

$ sudo port install phonon-qt5
.
.
.
--->  Applying patches to phonon-qt5
Error: org.macports.patch for port phonon-qt5 returned: can't read "qt_cmake_module_dir": no such variable

:-(

[mkae (Marko Käning)]

Uncommenting the post-patch phase actually seems to have solved this issue for me.

[RJVB (René Bertin)]

You'd probably also want to remove the patch that introduces MACPORTS_CMAKE_DIR into CMakeLists.txt ...

[mkae (Marko Käning)]

Probably, but I haven't checked that, as it did seem to work fine up to now. Which patch would that be?

[NicosPavlov]

Cc Me!

[mkae (Marko Käning)]

OK, Michael's commit r140960 is not yet sufficient. The phonon-qt5 subport is still missing...

​This does work for me.

[RJVB (René Bertin)]

phonon and phonon-qt5 updated to 4.9.0

[chrstphrchvz (Christopher Chavez)]

phonon has since been ​updated to 4.10.2, which is the latest release. Can this be closed?