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,