liballeg/allegro5

Audio addon doesn't build on macOS due to new API

Opened this issue · 8 comments

pedro-w commented

Recent changes to aqueue.m use kAudioObjectPropertyElementMain which was introduced by macOS 12.0.
Therefore it is impossible to build Allegro on 11.x or earlier.

allegro5/addons/audio/aqueue.m

Line 186 in 90d9131

propertyAddress.mElement = kAudioObjectPropertyElementMain;

See
https://developer.apple.com/documentation/coreaudio/1494464-anonymous/kaudioobjectpropertyelementmain?language=objc

SiegeLord commented

We need to change our tests to run on OSX 11 to prevent this kind of stuff.

SiegeLord commented

In this case, maybe switching it to kAudioObjectPropertyElementMaster is enough.

SiegeLord commented

Hmm... switching to MacOS 11 runner did not reproduce this for some reason: https://github.com/liballeg/allegro5/actions/runs/8404727385/job/23016655631?pr=1546 How frustrating.

pedro-w commented

This is the error I got

/Users/Projects/allegro5/addons/audio/aqueue.m:186:31: error: use of
      undeclared identifier 'kAudioObjectPropertyElementMain'; did you mean
      'kAudioObjectPropertyElementName'?
   propertyAddress.mElement = kAudioObjectPropertyElementMain;
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                              kAudioObjectPropertyElementName
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:331:5: note: 
      'kAudioObjectPropertyElementName' declared here
    kAudioObjectPropertyElementName         = 'lchn',
    ^

so not in MacOSX11.1.sdk - maybe the runner uses a later point release?

This is what SDL did:
libsdl-org/SDL@b0dc670

I tried putting just

#ifndef MAC_OS_VERSION_12_0
#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
#endif

into aqueue.m and it compiled ok for me.

SiegeLord commented

We usually do this via something like #if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_VERSION_12_0

pedro-w commented

This gives me a headache but I think that's not the right thing here.

As I understand it the ..._MIN_REQUIRED and ..._MAX_ALLOWED are used to 'adapt' your SDK to generate output to run on the given range of OS versions, taking into account symbols that are introduced and ones that go away via deprecation.

In this case nothing really changed, only Apple added kAOPEMain as an alias for kAOPEMaster regardless of any MIN_REQUIRED versioning, starting from, I believe, SDK 12. They also deprecated kAOPEMaster.

Here #ifdef MAC_OS_VERSION_12_0 just means "Does my SDK know anything about macOS 12?" - it's defined for SDK >= 12 and not defined for earlier SDKs (like mine that caused the problem)

So #if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_VERSION_12_0 wouldn't work as-is because for earlier SDKs MAC_OS_VERSION_12_0 is not defined - but even doing what we normally do (replace by their numeric literal values
eg.

allegro5/src/macosx/osx_app_delegate.m

Line 133 in 85aa2f9

#if MAC_OS_X_VERSION_MIN_REQUIRED >= 1100

) I still don't think that's the right criterion.

SiegeLord commented

...this is headache inducing. I saw we use kAudioObjectPropertyElementMaster and eat the deprecation warning.

pedro-w commented