[RFC PATCH 0/5] XAudio PE conversion.

[Zebediah Figura (she/her)]

On 6/28/21 7:22 AM, Rémi Bernon wrote:
> 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?

I was planning to send a mail to the public lists of at least the 
largest distributions (Debian, Ubuntu, Fedora, Gentoo, Red Hat, Arch) 
asking how they'd like to see PE libraries packaged and used, or if 
they'd prefer not to package them at all. I don't necessarily expect 
consensus from this, but if only some of them want to ship their own 
dependencies, it seems feasible to make that optional in our build system.

> 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.

Yeah, I think that's one of the problems, we'll need some standard way 
to retrieve the linker search paths, like (say) MINGW_LD_LIBRARY_PATH...

As for compile time, my preferred solution would be something like 
x86_64-w64-mingw32-pkg-config (actually this sort of exists already 
IIRC, and may even be usable.)

>> * 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.

Are you advocating for a source import? I'd really like to argue against 
using a source import.

>>     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.

I'm not saying we should rely on them; I'm just trying to point out that 
we're not the only people that want them, and shouldn't operate under 
the assumption that we are.

Granted, I see Giovanni says that Debian's packages shouldn't really exist.

>>     (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. 

Is there any such global state? I was under the impression that it was 
all instance-specific.

> It may be a waste of disk space,
> but we could consider the prefix size issue to be a separate one.

I'm not talking about prefix size. Prefix size makes it worse, but even 
one extra set of libraries is too much as far as I'm concerned.

>> * 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,
>