On Tue, Mar 28, 2023 at 02:29:10PM +0200, Michal Prívozník wrote: > On 3/28/23 12:58, Andrea Bolognani wrote: > > It looks like virgdbusmock is used by > > > > networkxml2firewalltest > > virfirewalltest > > virsystemdtest > > virpolkittest > > > > The first three are Linux-only; the last one is ELF-only, which > > Windows isn't and I *think* even throwing MinGW into the mix doesn't > > change that. In any case, enabling polkit support on Windows is > > explicitly blocked at the Meson level, so that test will never be > > built on that platform. > > > > It looks like it might be feasible to sidestep the issue entirely by > > simply not builing this specific mock on Windows after all. > > NB, this is already pushed, so whatever comes out of this discussion > will need to revert that commit. I'm aware of that. I don't even mind if the currently merged solution is what ships with 9.2.0 and a better one, assuming we can come up with it, is implemented afterwards. > Now - Windows PE - are we really sure that it can't work on Windows? I > mean, I only have a vague knowledge on PE, but IIRC then the dynamic > linker does symbol resolution that's very similar to ELF. IOW, the first > .dll to provide the symbol (i.e. our mock) wins the race. > > I'm not saying our mock works on Windows as is. Heck, we don't even run > !mock tests on Windows. We run no tests there. But if PE was able to do > mocking, then not compiling this would be pity. I'm not sure what the "PE" you talk about is. Anyway my point is that, at least as far as I can tell, all of the test programs that use virgdbusmock are effectively no-op on Windows, which means that mocking gdbus on Windows should not be necessary and thus not building the mock library on that platform should be viable. Other mocks might work on Windows, I'm not sure. I haven't investigated, and I'm not making blanket statements about the topic. I'm only discussing this specific mock, which is the one currently causing us grief and which looks like we could simply stop building on Windows without losing anything in the process. -- Andrea Bolognani / Red Hat / Virtualization
