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.
On 6/23/21 1:38 PM, Alexandre Julliard wrote:
"Zebediah Figura (she/her)" zfigura@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.
Not least because I'm not convinced that "Linux distros don't care about backwards compatiblity", or (as implied) that they don't care about philosophical correctness. I get the impression rather that some libraries don't care about backwards compatibility, and don't give distributions a choice in the matter. I'd really like to not see us become one of those, at least with respect to not giving distributions a choice. And I think that distributions broadly *do* care about philosophical correctness (as arises from practical correctness!) as evidenced by the Debian/Fedora/Gentoo policies linked earlier in this thread [1] [2] [3]. (Yeah, they're mostly talking about source imports, but some of the arguments apply to submodule-type dependencies as well.)
I get that we may have been burned in the past by breakages that have been the distribution's fault, but I think the response to that shouldn't be to break off negotiating with them and do what we think is right.
Now, with that said, here's some reasons, which I'm hoping are both strong and practical, that we should rely on distribution packages. Some arguments for not embedding or static linking don't really apply to PE dependencies, because they really are a special case. But others do:
* 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 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.
* 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
(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.
* This might not be under consideration, but I'll mention it anyway: We may have gotten used to the appwiz prompts, but they're honestly an awful user experience.
* Submodules are not fun to deal with, particularly the part where 'git submodule update' forces you off a branch.
ἔρρωσθε, Zebediah
[1] https://wiki.debian.org/EmbeddedCopies
[2] https://fedoraproject.org/wiki/Bundled_Libraries
[3] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
[4] As a bit of an aside, this may be my top complaint about modern dependency management. It makes things easier for the project maintainer, and for people who work on the project all of the time, because they have to build everything from source anyway. And it makes things easier for the end-user, because they don't need to take any extra steps when installing [and often need to take less!] But it makes things much worse on the developer of a downstream/upstream component, or on the end user who needs to compile the package for some reason.
[5] https://packages.ubuntu.com/search?suite=hirsute%C2%A7ion=all&arch=any&a...
[6] https://martchus.no-ip.biz/buildservice/#package-search-section?name%3Dmingw...