[PATCH 1/2] xaudio2: Fix support for FAudio 19.06 and newer

[Ethan Lee]

I could add F3DAudioInitialize8 separately, but it would mean everybody has to update to 19.05.0x for that def to go away, so the packaging situation doesn’t improve much there. I could possibly do something like FAPOFX_Create7 (well, it could be 5 since it’s xapofx1_5, but it could also be 7 since it’s the XAudio 2.7 spec…?) but that just makes FAudio’s API really confusing, since we would have some of the spec targeting 2.7 with 2.8+ as extension methods and other parts targeting 2.8 with 2.7- as extension methods. The real killer is CommitChanges, which is for sure stuck since it was an entirely bogus function and the old version should not exist at all. I could _maybe_ write in something like...

/* For build compatibility. This function was a stub to begin with, so do nothing. */
#define FAudio_CommitChanges(x)

… but that only fixes compile compatibility. The ABI increment would thankfully catch it since, presumably, this would only be an issue if someone updated FAudio but not Wine, so the old Wine would still look for libFAudio.so.0, but that’s just moving the issue to a different spot. Same applies to FAPOFX_CreateFX.

-Ethan

> On May 1, 2019, at 2:31 PM, Alexandre Julliard <julliard at winehq.org> wrote:
> 
> Ethan Lee <elee at codeweavers.com> writes:
> 
>> All of the changes are relatively easy to avoid until you get to
>> CommitChanges, which was completely wrong to begin with. It was either
>> wait and let more software become dependent on the incorrect function
>> signature or break right away and get the unavoidable pains out of the
>> way sooner than later. Either way, these ifdefs were going to
>> happen. Breaking compatibility for one single function seemed really
>> awful, so I tried my best to update the rest of the API to be more
>> consistent across the board to justify the breakage a bit more (for
>> example, properly making 2.8+ functions with the ‘8’ suffix). My hope
>> is that this will keep us from having to break it again in the future.
> 
> You can add the fixed function with a new name, and later on deprecate
> the broken one. Breaking compatibility this way is bad, particularly
> given the current packaging situation.
> 
> What's even worse is that old code no longer builds with the new
> headers, so once you upgrade the library it becomes impossible to do
> bisects and the like. Please rethink this change.
> 
> -- 
> Alexandre Julliard
> julliard at winehq.org