[MacPorts] #69832: phonon-qt5: please update the port so that it builds on Sonoma
MacPorts
noreply at macports.org
Fri Apr 26 22:42:19 UTC 2024
#69832: phonon-qt5: please update the port so that it builds on Sonoma
--------------------------------------------------+-----------------------
Reporter: barracuda156 | Owner: michaelld
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.9.3
Resolution: | Keywords: sonoma
Port: phonon-qt5, kde-extra-cmake-modules |
--------------------------------------------------+-----------------------
Comment (by RJVB):
Please have a look at what is being warned against here, and don't pretend
that these *are* errors instead of being handled as such. It's not
necessarily a coding error, just like not stuffing all possible cases into
a switch statement isn't. I can reproduce this symptom with clang-16 and
17 so it's not something Apple-specific that they have deemed crucial in
their infinite loop wisdom.
Look at this one for instance:
{{{
:info:build
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_phonon
/phonon-
qt5/work/phonon-4.11.1/phonon/experimental/objectdescription.h:40:35:
error: integer value 65536 is outside the valid range of values [0, 7] for
this enumeration type [-Wenum-constexpr-conversion]
1705 : :info:build
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_phonon
/phonon-
qt5/work/phonon-4.11.1/phonon/experimental/objectdescription.h:40:35:
error: integer value 65536 is outside the valid range of values [0, 7] for
this enumeration type [-Wenum-constexpr-conversion]
1705 :info:build typedef
Phonon::ObjectDescription<static_cast<Phonon::ObjectDescriptionType>(Phonon::Experimental::VideoCaptureDeviceType)>
VideoCaptureDevice;
}}}
There isn't even an assignment or use of a value here. In this case it's a
friggin typedef but none of the other locations I looked contain an
obvious use of an l-or-rvalue. So, no, I'm not going to be filing bug
reports against phonon about something that from where I stand could just
as easily be a compiler bug.
Clang-15, clang-12 and earlier and GCC-12 all compile this code without
fussing, and it's not like Phonon has proven itself to be problematic, not
for me at least. I've been using it on a daily basis for years and can't
recall ever having seen a crash in or that could be traced back to Phonon
code. So that's the alternative, less shocking workaround: blacklist
clang-16 and newer.
--
Ticket URL: <https://trac.macports.org/ticket/69832#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list