[RFC PATCH 0/5] XAudio PE conversion.

[Alexandre Julliard]

Rémi Bernon <rbernon at codeweavers.com> writes:

> On 6/25/21 2:38 PM, Jacek Caban wrote:
>> On 6/23/21 8:38 PM, Alexandre Julliard wrote:
>>> 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.
>> 
>> I agree that it's a good way to move forward.
>> To implement it, we will need to build dependencies with winegcc
>> (rather than plain mingw). I did experiment with it last year, you
>> may see it here:
>> https://github.com/cjacek/wine-addons
>> While the build system itself is just a rough draft and needs 
>> rethinking, it shows how to build static libs with winegcc (it links
>> them into standalone PE files, but they should be ready to
>> statically link to Wine modules as well).
>> We will probably also need such static libs to be more portable by 
>> getting rid of libgcc dependency, but that's a latter step.
>> Jacek
>> 
>
> Hi all!
>
> I went ahead on this approach, to see how nicely this could be
> integrated into Wine build, things well pretty well, and I reached a 
> point where I'm quite happy with the result.

Sorry about the late reply, I finally found the time to look into this.

I like your idea of using the Wine makefiles and bypassing the upstream
build system. I'm not convinced that it can work in all cases, but when
it works it definitely makes things a lot easier.

> The "wine-ext" repository references a fork of every dependency as a
> submodule. It needs to be cloned somewhere, with
> "--recurse-submodules", and then its path provided to "configure
> --with-wine-ext=<path>", which will check that its "VERSION" file
>  number is what current version of Wine expects.

That would make it hard to do bisects. You'd need to be able to extract
multiple versions at once, or switch wine-ext commits to follow Wine, at
which point we would be reinventing git submodules.

> (I'm also not completely sure if it makes a real conceptual difference
> with including these sources directly in Wine tree, but I can see how 
> this is a bit "cleaner".)

Maybe a little cleaner, but I'm thinking that importing the sources
would save a lot of trouble. Especially since with your approach we only
need to import *.[ch] and not the rest of the project.

> * There's some remaining dependencies, although I thought maybe they
>   weren't the most important ones, and maybe a unixlib split could be
>  more appropriate:

More important ones would be GnuTLS and libxml2. It may be interesting
to see how well GnuTLS works with your scheme.

-- 
Alexandre Julliard
julliard at winehq.org