On 8/31/22 07:51, Henri Verbeet (@hverbeet) wrote:
It's mostly to avoid having to import more code than necessary. And of course for people who work on both vkd3d and Wine, using the same helpers makes life easier.
I agree that it's no big deal for list.h. I was going to look into sharing more things, like wine/debug.h or the idl headers, but I assume that's not desirable either?
It would depend a bit on the specifics, but most likely not, no. As a general principle, I think vkd3d would like to avoid cases where we'd tell people things like "Please fix this in Wine instead" or "You can't change that internal header because it would break Wine".
I know @zfigura has opinions on this subject as well, and I don't want to get too far ahead of those, but to touch a little on the subject of non-Wine users/contributors, I think it's important enough to attempt to attract those that I'd tell them "vkd3d will go out of its way to accommodate your use-cases, even if that makes things slightly harder for us as Wine developers." Going by what you wrote above, I think that's the opposite of how you see things, which is a bit unfortunate. :-\
I'm not sure I have opinions about attracting vkd3d users or developers per se, although I agree with Henri's thoughts here.
What I do find baffling is the idea that omitting the private headers is easier, or preferable, to simply importing the vkd3d source code verbatim. That is, it seems like modifying vkd3d includes is more work, both for us, and for packagers. Note also that packagers really don't like it when we make local modifications to bundled code, and I don't blame them.
I find this especially baffling when we seem to take the opposite position elsewhere in Wine; there are multiple places where we duplicate code across modules rather than introducing helper libraries (or using #include, or PARENTSRC). dmobject.c in DirectMusic in particular comes to mind, though there are other partial copies as well. What makes this case different?