On 6/23/21 5:22 PM, Zebediah Figura (she/her) wrote:
On 6/23/21 7:37 AM, Rémi Bernon wrote:
I'm sending this as an RFC for now as there's been some discussion already about how to handle PE dependencies. I think the approach I'm taking here, by including FAudio headers directly in the source and loading it dynamically is the easiest way, and the least disruptive for building and running Wine, if not the cleanest. All the other solutions have higher friction, either on third party packages, or on the system distribution.
I don't think this is a very good idea, for several reasons:
- firstly, it's a huge amount of imported code;
I honestly don't think it is.
- secondly, the headers can easily change in the near future (and FAudio
has usually taken a loose approach to compatibility);
From what I could see it's usually okay, with new functions and structures added when they require a new ABI.
I don't see how this is so different from the current situation, as the current source shows it, we only check for the new function presence in the public headers.
The struct changes could be a problem, but only if we don't control the distribution of the PE FAudio. If we consider FAudio to be provided by Wine Mono for instance, it's merely a matter of making sure Wine Mono updates also update the headers here.
- thirdly, at least some distributions actually explicitly don't like
this [1].
This more precisely applies to sources, and sources which are already packaged as separate Debian packages. This is not the case here, and going that way is an entirely separate approach which IMHO has a good number of downsides.
As I've said, I think it's past time we ask distributions what they actually want, and work with them accordingly. My guess is it'll be some variation of pkg-config.
I don't think this is only a matter of discussion with the distros.
Having the dependencies provided by the system creates a much higher friction when building and running Wine from source.
Although I like the idea in theory, it's something I don't look forward to. Multi-arch is already so much of a mess than people started relying on container to build things in a sane environment.
So far Wine will be the first and probably only user ever of these new MinGW dependencies, and I don't think it's nice to delegate this to distros.
We can probably use (cross-)pkg-config for the build-time discovery (however bad it will be to integrate to configure, I tried but quickly bailed out), but then comes the problem to how to load the DLLs at runtime.
We usually compile-in the SO name, because dlopen has a set of builtin search paths, but that won't work with PE file, unless we add such paths to Wine loader.
I can also pretty easily see DRMs or anti-tamper mechanisms trigger if an unknown module is loaded from some non-standard location.
Overall this seems way more complicated, and IMHO too much for this particular case.
Upstream FAudio now has a pure Win32 backend, which makes it much easier to build as PE. This was never a requirement, and this series should work too with the SDL2 backend, as it tries to load Wine Mono SDL2 and FAudio as a fallback after trying from the prefix system libraries.
It could help the transition though, and is going to be required anyway to support WMA decoding. Right now, with or without the Win32 backend, this would also introduce a functional regression as although supported by the new FAudio Win32 backend, it also depends on the WMA decoder MF transform to be implemented, which isn't the case yet in Wine.
What if Wine is built without MinGW? Do we care about that case? If we don't care about it for XAudio, what about other libraries?
Is this still something we should worry about with the PE conversion? I don't see any sane path ahead if we add that problem on top, unless we just include FAudio source and be done with it.
To be completely honest I don't really understand the state of XAudio. Having just this thin shell just makes everything more complicated than it needs.
The DLLs are pretty useless without FAudio, so either we should delegate the build of fully functional XAudio DLLs to FAudio which it already (partially) supports, or we should be able to build fully functional XAudio DLLs directly in Wine tree.
This remarks only applies to some of the dependencies, not ones where they are only part of the functionality, or, like winex11.drv just not possibly integrated, but it also definitely applies to, say, vkd3d.
I don't completely understand [1] why it's separate and IMHO it makes integration and working on both Wine and vkd3d just horribly painful.
[1] Well I understand source ports, but I don't see why having it live in Wine would make source ports more complicated. I understand wined3d is already used that way, and it should be pretty much possible to do the same for vkd3d.
Cheers,