On 8/31/21 1:57 PM, Rémi Bernon wrote:
On 8/31/21 8:06 PM, Zebediah Figura (she/her) wrote:
(1) I really don't want to have to build any libraries that aren't part of Wine. More importantly, I don't want anyone who's not a regular Wine developer to ever have to build any libraries that aren't part of Wine. Also, if I do need to build (say) libvkd3d-shader, I want to *only* have to build libvkd3d-shader and not all of the Wine dependencies at once.
This is quite likely the only thing that holds me back from contributing to wine-mono (not that this is entirely Esme's fault; the problem affects mono upstream, although wine-mono has doubled down on it)
(Well, things like zlib is clearly not part of Wine, but TBH I don't really see how vkd3d is not a part of Wine.)
(Well, vkd3d is worked on almost exclusively by Wine developers, and hosted on winehq.org, but it's really meant to be a separate project usable outside of Wine. That said, if it were just vkd3d I probably wouldn't complain—after all, if we hadn't decided to split out vkd3d into a separate library all of that stuff would have been in Wine anyway.)
With the PoC you could already be working on the dependencies sources in the "wine-ext" umbrella project, building whichever Wine module depends on it to test it. If you don't need to build any Wine module to test it, then just build the project with its own build system.
Then, having a separate umbrella project has its drawbacks and I agree with Alexandre here that it makes bisection inconvenient. But even if we consider having the sources included in Wine you could very well have a configure flag to point to an alternate source location, while still using Wine makefiles to build the corresponding Wine module.
I may have miscommunicated; what I'm getting at is that I currently don't have to compile, say, libgnutls, and I would like to continue not having to compile libgnutls. Ideally I'd like to be able to link to pre-compiled static and shared libraries, and even more ideally I shouldn't have to manually set up configure to find them. Granted, without integrating those into a package somehow this is going to be difficult.
I guess the thing that makes this painful (in the projects I have worked with that do submodules, most prominently Proton and Mono) is twofold:
(1) build system recursion makes full builds *much* slower even when there's nothing to build. Granted, your PoC makes this a non-issue, but I'm also much less optimistic than Alexandre that trying to bypass projects' build systems is a good idea. Also granted, there are ways to get around this regardless...
(2) full builds are much slower anyway. This is particularly a problem for non-regular contributors [or even non-contributors who want to build a project from source, which is quite common!] It's also a problem if we end up compiling subprojects using Wine's tooling somehow, because that can easily change a *lot*.
Granted, I haven't actually tried, maybe the number and scope of subprojects we actually have makes this not much of an issue. But the number looks comparable to those projects that I hate dealing with, and the scope doesn't look that different...