On Fri, May 24, 2019 at 6:34 PM Thilo Borgmann <thilo.borgm...@mail.de> wrote:
> Am 22.05.19 um 14:27 schrieb Thilo Borgmann: > > Am 22.05.19 um 01:41 schrieb Jan Ekström: > >> Hi, > >> > >> On Tue, May 14, 2019 at 4:16 PM Thilo Borgmann <thilo.borgm...@mail.de> > wrote: > >>> > >>> $Subject > >>> > >>> Tested compilation only, sanity test actually using it appreciated. > >>> > >> > >> Thanks for the patch. To be completely fair, this is not to fix > >> compilation for specific target systems, but rather to fix compilation > >> on older SDKs (building with newer SDKs you can still build aiming for > >> macOS starting from 10.9, for example). > >> > >> I didn't notice a patch landed on the encoder side that utilized the > >> defines without further checking/ifdefs. Too bad. I think I > >> specifically didn't yet merge the full/limited range patch on the > >> decoder side due to related reasons. > >> > >> I did notice that VLC just re-defined these enum values themselves to > >> stop needing to have ifdefs depending on which SDK is being utilized > >> ( > https://github.com/videolan/vlc/commit/1b7e1c4bfcda375e2d4e657135aeaf3732e44af2#diff-a11cdb805d111956af60619d7dfa022bR735 > ). > >> I wonder if we should have a helper header that would re-define these > >> enum values with their name. That way the code would look correct, and > >> the resulting binary has the same features independent of the SDK it > >> had been built under. > >> > >> What would be the opinion of people on a solution like this? > > > > Tested with a local definition of the symbols (like a would be header > would do). > > Seems to work for building with -macosx-version-min=XXX. > > > > Also checked with VLC, they do these checks via thinks like: > > > > #ifndef MAC_OS_X_VERSION_10_13 > > ... > > #endif > > > > Wich might be a better alternative to what I suggested. > > > > Thus I would be fine with a helping header. > > If nobody else cares, should I try to come up with something like this? Or > do you want to? > If you're willing to maintain the header as new values are added, it will make it easier to read the code. > > -Thilo > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".