[RFC PATCH 0/5] XAudio PE conversion.

[Rémi Bernon]

On 6/28/21 5:48 AM, Zebediah Figura (she/her) wrote:
> Sorry for the slow reply, I'll admit I didn't really want to get into an 
> involved discussion, and I don't particularly expect to get anywhere, 
> but I'd at least like to try to explain my reasoning.
> 

Sorry if the discussion sounds involved, I think it's interesting to 
have this discussed, and even if I have some preferences right now, I'm 
trying to be open to being convinced otherwise.

> On 6/23/21 1:38 PM, Alexandre Julliard wrote:
>> "Zebediah Figura (she/her)" <zfigura at codeweavers.com> writes:
>>
>>> I know that dependency management (and ABI compatibility, for that
>>> matter) has fallen out of style in some circles, in favor of
>>> statically linking everything or shipping all your dependencies, but I
>>> really don't think that's a good thing, it has easily visible negative
>>> effects, and while I don't really want to get into an argument over it
>>> I also don't want to see us adopt that philosophy without question.
>>
>> It may be questionable from a philosophical standpoint, but that's the
>> world we live in. Linux distros don't care about backwards
>> compatibility, and I have no reason to believe that this is going to
>> change, or that they would do a better job with PE packages.
>>
>> And honestly, building our dependencies as PE and linking them
>> statically would make things so much easier for everybody, that there
>> would need to be strong practical reasons to go out of our way to start
>> relying on distro packages for this. A general dislike of the approach
>> is not good enough IMHO.
> 
> Mostly what I'm trying to advocate for in this thread is that we ask 
> distributions what they want instead of deciding for them. Just because 
> static linking might be easier for them doesn't mean it's what they 
> actually want, and I think there are salient and good reasons why they 
> wouldn't want it. Now, if we have that conversation and nobody wants to 
> ship dependencies themselves, I'm prepared to shut up and deal with the 
> decision; I won't be happy about it, but I seem to be in the minority at 
> least among Wine developers here.
> 

Let's say we ask, what are we going to consider as a good enough effort 
from our side?

Would it be enough to ask Debian's and RedHat's MinGW package 
maintainers (who already maintain a few MinGW packages) if they would be 
ready to make a few more, and hope that the other distributions will follow?

According to https://pkgs.org/search/?q=mingw, among distros which 
aren't apparently based on deb/rpm packages, Alpine, Arch or Solus don't 
have any MinGW packages yet except for the runtime itself. Also I'm sure 
that website also misses a few popular yet exotic distros.

Looking that the packages there, I can already spot differences between 
Debian, RedHat (and others) approaches, going over a few ones, I found 
already:

Debian: /usr/i686-w64-mingw32/{bin,include,lib}
RedHat: /usr/i686-w64-mingw32/sys-root/mingw/{bin,include,lib}
Solus: /usr/share/mingw-w64/i686-w64-mingw32/{bin,include,lib}

This is not necessarily an issue but if we embed default search paths 
into Wine, this has to be taken into consideration.

It also means that we would need to make it dynamically configurable, 
and even if the distro build scripts may override the default, once 
built it would be bound to a specific filesystem organization.

> * Projects that import source take so much longer to build. That applies 
> whether the source is baked in, statically linked, or even built as a 
> shared library. The last two cases actually often get worse because the 
> build system needs to recurse (but baked-in source has its own 
> problems.) This is probably the top reason I absolutely hate 
> contributing to wine-mono, and why although it's my job to work on 
> Proton I avoid its build system like the plague (preferring instead to 
> compile individual Wine modules). [4]
> 

I think there's different scale of dependencies, and I believe the 
discussion is only valid for the small ones. However inconvenient Wine 
Mono and Gecko are to build, I don't think it's a good idea to consider 
including them in Wine.

FWIW I don't think we have to stick to upstream build system and have 
recursive make anywhere if we don't want to. We only need the code to 
implement our DLLs, not the build system.

>    I as a DirectShow developer need to build GStreamer anyway, for 
> various reasons (I need the latest version, or to fix an upstream bug, 
> etc.) But I've never needed to compile FAudio from source, and I don't 
> want to have to take that extra time during a Wine build. Relying on my 
> distribution package makes things much easier for me.
> 
> * Static linking makes bisects painful. You have to rebuild the 
> downstream project every time. Shared libraries would be a lot better, 
> for this and for other reasons. Even if the decision ends up being to 
> distribute libraries ourselves I'd like to advocate that they be shared 
> rather than static.
> 

System provided libraries can also be problematic when the regression 
comes from the system update.

And as I explained in my reply to Jacek, I don't think building these 
dependencies separately from Wine is convenient either. If that's the 
plan, I'd rather go through the system distribution.

> * By linking libraries statically, or by linking them shared and 
> distributing them ourselves, we are taking up more disk space that could 
> be shared. This is obviously a garbage argument because no other 
> application is using PE libraries, except that:
> 
>    (a) some distributions [5] and unofficial repositories [6] do ship 
> MinGW libraries, which means that there *is* a demand for them outside 
> of Wine, and
> 

I don't think we should rely on user-contributed packages. Either the 
distro have what we need, or we should provide the packages as an 
alternative.

>    (b) if we link them statically, even within Wine we'd be sharing many 
> libraries across several modules [libvkd3d and libvkd3d-shader across 
> d3dcompiler_*, d3d12, dxgi; libfaudio across all of the many xaudio 
> modules; even libmpg123 across l3codeca.acm and mp3dmod!], and to avoid 
> this we'd have to use some sort of manually defined static -> shared 
> shim. At that point distributing the shared library seems like less work.
> 

Are the xaudio libraries supposed to share state on Windows? If not then 
I think we should probably not either. It may be a waste of disk space, 
but we could consider the prefix size issue to be a separate one.

> * Submodules are not fun to deal with, particularly the part where 'git 
> submodule update' forces you off a branch.
> 
I agree, but I don't think we need to have that. We could just pass the 
source location as a configure flag, regardless to how that has been 
pulled, and consider the dependency as missing if sources are not provided.

Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>