[RFC PATCH 0/5] XAudio PE conversion.

Rémi Bernon rbernon at codeweavers.com
Mon Jun 28 11:13:39 CDT 2021


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.
-- 
Rémi Bernon <rbernon at codeweavers.com>



More information about the wine-devel mailing list