[RFC PATCH 0/5] XAudio PE conversion.

[Rémi Bernon]

On 8/31/21 8:06 PM, Zebediah Figura (she/her) wrote:
> (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)
> 

(Well, things like zlib is clearly not part of Wine, but TBH I don't 
really see how vkd3d is not a part of Wine.)

With the PoC you could already be working on the dependencies sources in 
the "wine-ext" umbrella project, building whichever Wine module depends 
on it to test it. If you don't need to build any Wine module to test it, 
then just build the project with its own build system.

Then, having a separate umbrella project has its drawbacks and I agree 
with Alexandre here that it makes bisection inconvenient. But even if we 
consider having the sources included in Wine you could very well have a 
configure flag to point to an alternate source location, while still 
using Wine makefiles to build the corresponding Wine module.

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

Anyway, I'm not sure vkd3d if was in question here. I mentioned it 
previously as an example of external dependencies which I would find 
nicer to have integrated with Wine build (alongside with wine-mono and 
wine-gecko but they're way beyond reach), but I don't know that we're 
planning on any change there.

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

Well, my PoC didn't use shared libraries because it seemed to be the 
initially intended way with Jacek idea. However, using Wine makefiles 
it's really just a matter of few lines and a specfile to make them DLLs 
instead.

> (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'm sure they dislike the wine-mono / wine-gecko situation more because 
we're downloading them separately from an untrusted source rather than 
because they embed a lot of already packaged third-party dependencies.

FWIW building them as part of Wine would probably be much appreciated, 
regardless of their content.

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