Request for discussion: Using PE libraries for Wine dependencies

[Jacek Caban]

Hi Vincent,


Thanks for bringing it up. I gave it some thoughts and below is how I 
envision this could be done.


Wine has very nice and pure build system. I think that's something 
definitely worth preserving, but at the same time keep building fully 
functional Wine package simple. What we'd need is a separate repository 
which would make building dependencies easy and optionally handle 
building even core Wine. We would provide MSI-based downloadable 
installers like we do for other addons as a fallback, but intended use 
would involve shipping Wine with addons. I'd think about those repos as 
Wine core (the platform including both runtime Windows implementation 
and SDK to build for it) and a separate new "wine-dist" repo (a tool to 
build that manages building Wine distribution). As such, Wine itself 
would be independent like it is now, but at the same time could be 
optionally managed by the new build system.


Wine would need to be aware of addons header location. It would look for 
some standard places and have a configure option to specify a custom 
one. makedep would be aware of that. We would use only headers, no 
binaries. This way a downloadable, headers-only package would be enough 
to build core Wine from sources (although it's still not perfect, better 
ideas welcomed).


Wine addons would be marked as builtin and installed in standard Wine 
location (we may need to revisit what that standard location is). MSI 
files would install files to system32. Then loading them would be as 
easy as LoadLibraryW(L"wine-faudio-1.dll") or similar. We'd probably 
want a helper that would optionally invoke addon installer in case of 
failure.


winegcc and other Wine tools could be used as a powerful cross platform 
tool for building targeting Wine. We could use that for addons builds. 
The main supported way of building addons would be with mingw-backed 
winegcc that that's what we'd ship. winegcc provides, in theory, an easy 
way to build things as ELF winelib files. So if someone shows up trying 
to build that for powerpc, tools would be in place and patches welcomed. 
In theory it could be a matter of using the right configure options. In 
practice, it would probably require quite a bit of tweaking.


Of course, building with winegcc is probably an extra complications and 
would need a serious Wine work first. mingw-backed winegcc is not quite 
ready to stabilize on, IMHO, but it's getting there and it would be 
interesting to experiment with it. I'm happy to help. If we could get 
things to work in "-mno-cygwin" mode, we could provide a stable and 
portable build environment. Building autoconf-based subprojects would be 
handled by our makefiles (similar to how you did it) and probably look like:

.../configure CC="$WINEGCC -b $target" --host=$arch-w64-mingw32


Now back to the repo that would handle addons. I imagine that it would 
make distributing fully functional Wine with simple ./configure && make 
&& make install. For that, it would do basic checks and handle multiple 
submodules. It will build winelib part of Wine, use that for building 
addons and build Wine runtime itself against fresh addons headers. It 
could even handle win32+win64 builds in a bit more friendly way than we 
do now.


All of that would be optional. If someone prefers to build Wine itself 
the usual way, there would be ./configure --with-system-wine or 
./configure --with-wine-objdir=... etc. Similar for other libraries: 
./configure --with-faudio-srcdir=... if someone prefers an alternative 
faudio version. It should be easy to make it very flexible and easy to use.


Optionally, I can even imagine bootstrapping cross toolchain as a part 
of the build. It's not too hard to build LLVM or GCC+binutils. I imagine 
that distros would better ship it themselves, but we could have an 
optional bootstrapping for a reference platform.


An important consideration is versioning and API stability. Of course, 
in this case, we don't control API of projects that we import, so we 
can't make a promise of API stability. Runtime detection seems easy: we 
need to rename module and mark it builtin, we may as well add ABI 
version to the name and increment it whenever ABI version of the library 
changes. Wine builds would try to load only the ABI version they are 
built against. What versions of headers do we allow as Wine to be built 
against is another question. Limiting that 1:1 mapping it tempting 
because of simplicity and avoiding #ifdefing.


Examples of the theoretical new repo use:


To build a complete Wine win32+win64 Wine package with additional addons 
and install the whole thing as a single:

./configure && make && make install


To build Wine addons using previously installed Wine (the standard way 
or with help if the new tool):

./configure --with-system-wine && make && make install


To build Wine addons, but use alternative SDL2 sources, without faudio:

./configure --with-faudio-sdl2dir=...  --without-faudio && make && make 
install


To build complete Wine with PE files and functional cross compiler on a 
distro that doesn't provide required tools:

./configure --enable-bootstrap-llvm


To have separated build dirs for Wine and addons (probably useful for 
developers doing multiple builds, I'd expect to use it):

.../configure --with-wine-objdir=path/to/main/objdir && make # builds 
Wine addons using tools from specified Wine builds

And in Wine tree:

.../configure --with-wine-addons-dir=...


So that what I came up with. It aligns with Vincent's thoughts in many 
places. And I'm sure there are other good solutions as well. Comments 
and ideas welcomed.


Cheers,

Jacek