Fix USE_SYSTEM_OPENAL to use system headers

[pastalian]

Even when USE_SYSTEM_OPENAL was enabled, the code directly included the bundled OpenAL headers, bypassing the system headers.

Since #include <AL/al.h> is not portable, use #include "al.h" instead.
https://cmake.org/cmake/help/latest/module/FindOpenAL.html

[pastalian]

Does anyone know why macOS can't find the OpenAL headers?
CMake seems to find OpenAL correctly and is passing the header path:
-- Found OpenAL: /Applications/Xcode_15.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/System/Library/Frameworks/OpenAL.framework
... -isystem /Applications/Xcode_15.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/System/Library/Frameworks/OpenAL.framework/Headers ... /Users/runner/work/1/s/rpcs3/Emu/Cell/Modules/cellMic.cpp ...

but it's still failing:
/Users/runner/work/1/s/rpcs3/Emu/Cell/Modules/cellMic.cpp:14:10: fatal error: 'alext.h' file not found

[hcorion]

Try setting -DUSE_SYSTEM_OPENAL=OFF in the build-mac.sh and build-mac-arm64.sh scripts.

[pastalian]

Thank you, that fixed it.
But this means USE_SYSTEM_OPENAL=ON is still broken on macOS. Is that OK with you?

[hcorion]

Yeah since it's a default we should figure out why it's not including the headers on Mac.
I think it might be straightforward though. Try adding something like
target_include_directories(3rdparty_openal INTERFACE ${OPENAL_INCLUDE_DIR})
to the OpenAL CMakeLists.txt, looks like we're just not actually referencing the include dirs.

[hcorion]

And you should revert the build.sh hacks we added, since the CI should be testing defaults.

[pastalian]

Apparently, macOS does not provide alext.h.
https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioFrameworks/CoreAudioFrameworks.html

The OpenAL framework provides an implementation of the the OpenAL specification. This framework includes these two header files:
al.h
alc.h

Maybe USE_SYSTEM_OPENAL should be disabled on macOS?

[elad335]

Is there a benefit to USE_SYSTEM_OPENAL? it can be dropped altogether otherwise.

Apparently, macOS does not provide alext.h. https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioFrameworks/CoreAudioFrameworks.html

The OpenAL framework provides an implementation of the the OpenAL specification. This framework includes these two header files:
al.h
alc.h

Maybe USE_SYSTEM_OPENAL should be disabled on macOS?

[pastalian]

Is there a benefit to USE_SYSTEM_OPENAL? it can be dropped altogether otherwise.

In general, on Linux, it's preferred to have the option to use system libraries instead of bundled ones.

• https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
• https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

This might not be as important on Windows or macOS, though.

[hcorion]

Yeah let's change the default of USE_SYSTEM_OPENAL on Windows and Mac to use false and keep it as true on Linux

[elad335]

68ac05f

If it fails on MacOS, force it being disabled instead of being an option.

[hcorion]

We don't want to disable, the user could install openal via brew in which case it would build fine