A change in Qt 5.11_beta3 leads to errors like:
CMake Error at phonon/experimental/CMakeLists.txt:23 (qt5_use_modules):
Unknown CMake command "qt5_use_modules".
asturmlechner |
Restricted Owners Package | (Owns No Changed Paths) |
A change in Qt 5.11_beta3 leads to errors like:
CMake Error at phonon/experimental/CMakeLists.txt:23 (qt5_use_modules):
Unknown CMake command "qt5_use_modules".
Built fine with Qt4 and Qt5 support.
No Linters Available |
No Unit Test Coverage |
Agh qt, why can't thou be backwards compatible 😿
Anyway.
It seems to me this would be more maintainable and less invasive by macroing qt5_use_modules for both Qt4 and Qt5, no? use_modules was only used to aid in not having to if branch all over the place and have to maintain repetitive target_link_libraries.
Depends how long you want to keep Qt4 support in there. When you drop it, then just all those else blocks will need to be dropped. A new macro would need to translate between the differences (Qt5::Widgets vs. QT_QTGUI_LIBRARY) and is obsolete again after Qt4-removal...
It's writing one macro which is basically a mirror of the other macro, versus manually doing what the macro would do. Having slept on this I think I'd prefer the macro. The way the release cadence is right now, we are looking at another year with Qt4 at least. When Qt4 gets dropped we'll need to go through all the cmake code anyway and get rid of all the cruft.
qt-gstreamer has qt4or5-macro'd everything, and I fixed their _qt4or5_component_names_to_qt_components macro rather than having to if-else their use of qt4or5_use_modules in 31 places. You could have a look at their FindQt4or5.cmake file and copy the relevant part for phonon.
(my fix, since it may take years until landing upstream: https://bugzilla.gnome.org/show_bug.cgi?id=795285)