I am having troubles with include path for OpenAL headers

[McSinyx]

Currently in Alure, OpenAL's al.h and alc.h are included as if they belong to the include path:

$ ack al\\.h
src/devicemanager.cpp
13:#include "al.h"

include/AL/alure2-alext.h
39:#include "al.h"

include/AL/efx.h
6:#include "al.h"

include/AL/alure2.h
10:#include "al.h"

$ ack alc.h
src/devicemanager.cpp
12:#include "alc.h"

src/context.cpp
16:#include "alc.h"

include/AL/alure2-alext.h
38:#include "alc.h"

include/AL/efx.h
5:#include "alc.h"

According to b5f5f96ae8489c8adbbc4a505b02a4d1f3787c03, this is to shadow broken OpenAL headers on some systems. During compilation of Alure and its examples, there is no error since the headers are in the source directory. However, if one wants to compile the example (or any program using Alure):

$ g++ -lalure alure-enum.cpp
alure-enum.cpp:8:10: fatal error: alure2.h: No such file or directory
    8 | #include "alure2.h"
      |          ^~~~~~~~~~
compilation terminated.

After changing "alure2.h" into <AL/alure2.h>, we get

$ g++ -lalure2 alure-enum.cpp
In file included from alure-enum.cpp:8:
/usr/include/AL/alure2.h:9:10: fatal error: alc.h: No such file or directory
    9 | #include "alc.h"
      |          ^~~~~~~
compilation terminated.

Since I believe OpenAL headers are installed in /usr/include/ for most distros, I added -I/usr/include/AL/ and it compiled alright. However, on NixOS, each package is separated in its own (kind of) fake root, e.g. al.h is at /nix/store/3dvrqgfh9ai8ay6pixjsd9k9qszvxq08-openal-soft-1.19.1/include/AL/al.h. Normally, if it is included as AL/al.h, nix-shell can handle the include path for it alright, but in this case, there might not be any pretty work around.

On the Cython wrapper I'm working on, I have to add /usr/include/AL/ to the include dirs, but I'm quite sure it is not portable, for instance, the host OS may have the header in /usr/local/include/AL/, or it is Windows. Is there any way we can make the compiler to find these OpenAL headers naturally?

[kcat]

Generally alure2.h would be installed in the same directory as al.h/alc.h. That way, alure2.h can include "alc.h" and "al.h"and it will find them in the same directory. Alternatively, the FindOpenAL.cmake module for cmake will provide the include path to use so "alc.h" and "al.h" will work (OpenAL Soft provides an import module that provides a target to get the same).

Otherwise, unfortunately, different systems would need different subdirs... AL/ on some, OpenAL/ on others, and nothing on some too. And particularly on Windows, the OpenAL SDK can be installed almost anywhere and the compiler has to be told where to look (the FindOpenAL module looks up its install location in the registry).

[McSinyx]

Thank you, I wasn't aware of FindOpenAL.cmake. Also I've seen project using find_package(ALURE) but not FindALURE.cmake in CMake Modules. From the FindOpenAL module, can I simply do substitution to create FindAlure or is there any special care needed?

I will try to build the Cython project using cmake and report back if any problem raises.

Edit: I'm especially curious about [HKEY_LOCAL_MACHINE\\SOFTWARE\\Creative\ Labs\\OpenAL\ 1.1\ Software\ Development\ Kit\\1.00.0000;InstallDir]: what would be the equivalence for Alure?

[kcat]

Also I've seen project using find_package(ALURE) but not FindALURE.cmake in CMake Modules.

Those are the same. find_package(ALURE) is a short-hand for including FindALURE.cmake (it also allows to pass options to the module, like REQUIRED to make configuration fail if it fails to find the package).

From the FindOpenAL module, can I simply do substitution to create FindAlure or is there any special care needed?

When building/installing Alure2, it provides Alure2Config.cmake. Using find_package(Alure2) in your project should also pick that up if it's found in one of the cmake modules paths. That module declares the Alure2::alure2 target for dynamic linking and Alure2::alure2_s for static linking Alure. So if you do

target_link_libraries(MyTarget ... Alure2::alure2)

it will ensure the appropriate include paths are set for both Alure and OpenAL.

I'm especially curious about [HKEY_LOCAL_MACHINE\\SOFTWARE\\Creative\ Labs\\OpenAL\ 1.1\ Software\ Development\ Kit\\1.00.0000;InstallDir]: what would be the equivalence for Alure?

There isn't an equivalent thing for Alure since it doesn't set a registry key like Creative's OpenAL SDK installer.

[McSinyx]

So if you do target_link_libraries(MyTarget ... Alure2::alure2) it will ensure the appropriate include paths are set for both Alure and OpenAL.

Thank you, that works beautifully! Since the problem is solved, I'm closing this now.

There isn't an equivalent thing for Alure since it doesn't set a registry key like Creative's OpenAL SDK installer.

As Alure2Config.cmake already provides enough resource for compilation, I think I don't need to write FindAlure2.cmake anymore, especially given my unfamiliarity with CMake. It is good to know that that is a registry key though (I haven't use Windows for, well, long enough)!