Add seperate defines for OpenAL Soft and MojoAL

[ACrazyTown]

Lime uses different OpenAL backends based on the target platform and build configuration. Currently there's only one define (lime_openal) that only lets us determine if any OpenAL backend is being used, but not what which one specifically.

[player-03]

I think I'd rather use a single define, with a value. That way, there can only be one set at a time, because setting a new value overwrites the first.

Also, the define should actually determine which backend gets used, otherwise there's no guarantee that it's correct.

[ACrazyTown]

I think I'd rather use a single define, with a value. That way, there can only be one set at a time, because setting a new value overwrites the first.

Yeah this could work too. My initial thought was that since both MojoAL and OpenAL Soft implement the core OpenAL API, the lime_openal define should be present always (also wouldn't break already existing code). However, MojoAL and OpenAL Soft might have some exclusive features that should be locked behind their respective conditionals.

Also, the define should actually determine which backend gets used, otherwise there's no guarantee that it's correct.

I'm not sure how to do this. I thought that the backend was decided when the target's NDLL is built. How would the backend be modified with a define if the necessary native code was not included?

[player-03]

My initial thought was that since both MojoAL and OpenAL Soft implement the core OpenAL API, the lime_openal define should be present always (also wouldn't break already existing code). However, MojoAL and OpenAL Soft might have some exclusive features that should be locked behind their respective conditionals.

I don't think that would be a problem, you can just do this.

#if lime_openal
//Some version of OpenAL is present.
#end

#if (lime_openal == "mojoal")
//The backend is MojoAL.
#end

#if (lime_openal == "soft")
//The backend is OpenAL-Soft.
#end

I'm not sure how to do this. I thought that the backend was decided when the target's NDLL is built.

Oh, right, those are in the NDLL. But that's ok, because defines from include.xml are passed through to Build.xml, so we should still be able to access them at rebuild time.

How would the backend be modified with a define if the necessary native code was not included?

To clarify: I mean that the same define should control both the native code and the Haxe code. After modifying the define in include.xml, you'd have to rebuild the NDLL, but that's perfectly fine. "The NDLL is out of sync" is a common problem that we know how to troubleshoot.

[ACrazyTown]

To clarify: I mean that the same define should control both the native code and the Haxe code. After modifying the define in include.xml, you'd have to rebuild the NDLL, but that's perfectly fine. "The NDLL is out of sync" is a common problem that we know how to troubleshoot.

Sorry, I'm a bit confused. If I understood it right, we'd have decide which target defaults to what OpenAL backend in include.xml and then in Build.xml decide which native library to build based on the value of the lime_openal define, right? If so, how would we compare the value of the define in the Build.xml? I looked through the documentation and unless I missed something obvious it seems like you can only check if the define is present and not what it is.

Also, would you happen to know if there's a part of Lime or some other hxcpp library that does something similar? I'm still wrapping my head around all these XMLs so would be helpful to have an example to base things off of

[player-03]

I looked through the documentation and unless I missed something obvious it seems like you can only check if the define is present and not what it is.

You're right, Build.xml can only check whether or not it's defined. I guess we can stick with the multiple defines approach, then.