[RFC PATCH 0/5] XAudio PE conversion.

Zebediah Figura (she/her) zfigura at codeweavers.com
Tue Aug 31 13:06:00 CDT 2021


I know I'm representing the minority opinion here, but I'd like to offer 
my objections anyway :-)

I think the solution I originally proposed doesn't make a lot of sense 
in retrospect. However, I don't like this one either.

I've tried to rethink my position to be more reasonable, and I'd like 
whatever solution we come up with to satisfy three things:

(1) I really don't want to have to build any libraries that aren't part 
of Wine. More importantly, I don't want anyone who's not a regular Wine 
developer to ever have to build any libraries that aren't part of Wine. 
Also, if I do need to build (say) libvkd3d-shader, I want to *only* have 
to build libvkd3d-shader and not all of the Wine dependencies at once.

This is quite likely the only thing that holds me back from contributing 
to wine-mono (not that this is entirely Esme's fault; the problem 
affects mono upstream, although wine-mono has doubled down on it)

(2) I would like bisecting dependencies to not be a pain. As someone who 
will be working on vkd3d a lot, this is quite important to me. Ideally 
this means that the dependencies should exist in shared libraries, not 
static ones.

I would also like to be able to develop in a separate tree, since git 
submodules are terrible for doing active development on a component. 
Rémi's proposed solution does not really allow for that as far as I can 
tell.

As an aside, I still think there is something to be gained in using 
shared libraries to reduce disk space. Almost all of our PE dependencies 
are not only shared across multiple DLLs, but will often be loaded 
multiple times in the same process (vkd3d, faudio, gnutls, libpng, zlib, 
freetype, mpg123 all come immediately to mind. To some degree we can try 
to abstract that out with our own shared-to-static shims, but that takes 
some work which I think is rather unnecessary.)

(3) Most importantly, I would like to coöperate with distributions. As I 
understand, they already don't like the way we distribute wine-mono and 
wine-gecko, and I don't think we should annoy them any further by going 
behind their back and distributing more pre-built libraries.

I know people here think that they won't want to distribute PE 
libraries, but I'm inclined to think that at least some distributions 
won't be happy with our proposed solution either. See [1] [2] [3] [4] 
for popular distributions trying to discourage source imports and static 
libraries. I get that we're a special case, and maybe distributions will 
think so too, but I really want to again argue that we shouldn't be 
making that decision for them.

ἔρρωσθε,
Zebediah

[1] https://wiki.debian.org/EmbeddedCopies

[2] https://fedoraproject.org/wiki/Bundled_Libraries

[3] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries

[4] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies



More information about the wine-devel mailing list