On 6/28/21 5:53 PM, Zebediah Figura (she/her) wrote:
On 6/28/21 7:22 AM, Rémi Bernon wrote:
On 6/28/21 5:48 AM, Zebediah Figura (she/her) wrote:
- 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 think there's different scale of dependencies, and I believe the discussion is only valid for the small ones. However inconvenient Wine Mono and Gecko are to build, I don't think it's a good idea to consider including them in Wine.
FWIW I don't think we have to stick to upstream build system and have recursive make anywhere if we don't want to. We only need the code to implement our DLLs, not the build system.
Are you advocating for a source import? I'd really like to argue against using a source import.
Not importing their source into Wine tree if we can find a better way (like hosting them separately, with some optional build integration), but I also don't think we should rule it out as a possibility so easily.
For instance, we are importing pieces of musl source into Wine already. From a security updates point of view (which is one of the reason to prefer system-distributed packages) I find duplicating and maintaining our own C runtime much more concerning.
Of course it's even harder to do otherwise, so I understand the rationale.