So I think I may have misunderstood or lost sight of goals somewhere along the way, let me try to review.
I think it makes the most sense to use one or more separate distribution packages for our PE dependencies, rather than distributing them as part of Wine, statically linking, or distributing them using our Win32-based addons system. I'm not sure just from reading this thread there's a general consensus regarding that, but I'm not sure I've seen anyone argue against it either.
Separately, I think it makes sense for Wine's libraries—seeing as they *are* (relatively, and mostly) high-level—to use MinGW libraries the same as any other MinGW-compiled program would.
It's not clear to me that this implies that we reverse the direction we're currently taking and try to make more use of the MinGW CRT, headers, and/or libraries. (I can understand the CRT part, though even then I have to wonder if there are differences that will matter.)
If it does, I'd like to understand why that's not possible, because it seems to me that we gave up on MinGW after they objected to taking the entire mingw-w64 project under the umbrella of Wine (and I don't think that was a reasonable thing for us to ask, given that mingw-w64's purpose is not to target Wine, but any conforming implementation of the Win32 API, and in practice mostly Windows.)
Now, on the assumption that using mingw-w64-compiled PE libraries is a reasonable thing to do...
On 4/13/20 11:38 AM, Jacek Caban wrote:
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can do
that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to do
build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free. Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
As a side note, a different and separated distro packages for, say, libxml2 built with winegcc could also have some use cases. That would be something potentially useful for cross compiling an application using winegcc, but not something for Wine to use internally.
I think 2/4 are referring to the same thing (at any rate, I see no reason not to give distributions the choice). I don't think I fully understand how 3 differs from 2/4, or how 6 differs from 5. Do you mean by introducing a meta-package which only exists for dependency purposes?
Anyway, if depending on mingw-w64 really is a dead end, I guess either 4 or 5 seems reasonable to me, though it's less clear that distributions actually would prefer 4. In particular, I notice:
* Suppose you want the versions of the PE libraries you ship to match the ELF libraries your distribution already ships. You can change the sources without too much difficulty, but how do you label the resulting package with regard to version? Naming it after the Wine version isn't great, especially if you're going to update those packages asynchronously...
* If a distribution (or even WineHQ) wants to update one of our 20+ packages, do they/we have to ship the whole wine-meta-distro again? (Maybe this isn't a problem, if the packages in question support partial updates...)
Ultimately I think this is something that actual distributors would have to answer, and I think we should probably bring some in on this thread.
If on the other hand we can depend on mingw-w64 libraries, I think we almost have to pick 5 over 4, for the simple reason that it's already done that way. There's an existing demand for mingw-w64 libraries which are distributed separately. Fedora already ships them. Arch doesn't (in fact, Arch doesn't even ship the mingw-w64 compiler), but they exist in the AUR as separate packages, and I myself use a third-party repository that ships mingw-w64 library blobs. (That's how I was able to write that msxml3 patch, in fact.) Debian/Ubuntu don't ship very many, but they do ship libz, and also development versions of a few other libraries.
Cheers,
Jacek