Rémi Bernon rbernon@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.