On Wed, 17 Apr 2024, Marvin Scholz wrote:
This fixes the checks to properly use runtime feature detection and
check the SDK version (*_MAX_ALLOWED) instead of the targeted version
for the relevant APIs.
As these things are pretty hard to think straight about, it could be good
with a more concrete example of what this achieves. I.e. if building with
-mmacosx-version-min=10.13, we can still use the macOS 10.15 specific
APIs, if they were available at build time, via the runtime check.
The target is still checked (*_MIN_REQUIRED) to avoid using deprecated
methods when targeting new enough versions.
---
libavdevice/avfoundation.m | 164 ++++++++++++++++++++++++++-----------
1 file changed, 116 insertions(+), 48 deletions(-)
The diff is pretty hard to read as is, but when applied and viewed with
"git show -w", it becomes clearer.
The changes from TARGET_OS_IPHONE to TARGET_OS_IOS is pretty subtle, iirc
TARGET_OS_IPHONE was any non-desktop platform (ios/tvos/watchos etc),
while TARGET_OS_IOS specifically is iOS. The change looks right, but it
might be good to spell this out as well.
Specifically also, that TARGET_OS_IPHONE covers a whole class of OSes,
while TARGET_OS_IOS is one OS - but the version defines for that OS are
__IPHONE_OS_VERSION_MIN_REQUIRED and __IPHONE_OS_VERSION_MAX_ALLOWED.
+ /* If the targeted macOS is new enough, this fallback case can never be
reached, so do not
+ * use a deprecated API to avoid compiler warnings.
+ */
This sentence gets somewhat warped up at some point, so I don't think it
exactly means and is understandable as you meant it.
What about this:
If the targeted macOS is new enough, use of older APIs will cause
deprecation warnings. Due to the availability check, we actually
won't ever execute the code in such builds, but the compiler will
still warn about it, unless we actually ifdef out the reference.
Outside of what the patch does, I see the existing file uses this
construct in a few places:
#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
I think it would seem more consistent to update this to use TARGET_OS_OSX
instead of negating TARGET_OS_IPHONE - or is there something I'm missing?
As for alternative ways of doing this, that would be less unwieldy - I
have something like this in mind:
#define SDK_AT_LEAST(macos, ios, tvos) \
(TARGET_OS_OSX && MAC_OS_X_VERSION_MAX_ALLOWED >= macos) || \
(TARGET_OS_IOS && __IPHONE_OS_VERSION_MAX_ALLOWED >= ios) || \
(TARGET_OS_TV && __TV_OS_VERSION_MAX_ALLOWED >= tvos)
#if SDK_AT_LEAST(__MAC_10_15, __IPHONE_10_0, __TVOS_17_0)
We could add similar macros for both SDK_AT_LEAST and
TARGET_VERSION_AT_LEAST, and variants for different combinations of
macos/ios/tvos for when we don't want to specify all of them.
We can't use defined(macos) etc within this context though, so if we want
to go this way, we'd need to start out with ifdefs for all the defines we
use, like this:
#ifndef __MAC_10_15
#define __MAC_10_15 <constant value>
#endif
There's of course a bit of fragility here, we need to make sure that we
actually copypaste the exact right value here. But on the other hand, we
even could make it intentionally something else, e.g. like this:
#ifndef __MAC_10_15
// If the SDK doesn't define this constant, the SDK doesn't support this
version anyway, and we won't end up selecting it, so just use a dummy
value instead.
#define __MAC_10_15 99999999
#endif
What do you think, does any of that seem like it would make the code more
manageable?
// Martin
_______________________________________________
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".
