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