On Tue, Sep 04, 2018 at 04:31:27PM +0200, Andrea Bolognani wrote: > On Tue, 2018-09-04 at 16:11 +0200, Erik Skultety wrote: > > On Tue, Sep 04, 2018 at 01:01:34PM +0200, Andrea Bolognani wrote: > > > Up until now, we've been considering MinGW builds as > > > part of the respective project, at least when it > > > comes to grouping them. This, however, does not quite > > > work for a number of reasons: > > > > > > * MinGW builds have their own workspace, separate > > > from the native one. It goes further than that: > > > even the 32-bit and 64-bit builds use a workspace > > > each, which goes to show that grouping all three > > > together is inaccurate; > > > > Well, I'd say that if someone cares enough about libvirt mingw builds, then they > > probably care about both ABI versions in which case they'd most probably prefer > > not having to specify for which x86 arch build they're interested in, therefore > > having both of these in the same project playbook, e.g. libvirt+mingw. > > Fair enough, but that's still supported quite naturally by using > 'libvirt+mingw*', whereas the opposite wouldn't be true if we I still don't see a reason why anyone would really prefer one ABI over the other instead of just simply running the build for both. > grouped them together; moreover, grouping them together ignores > the fact, mentioned above, that they already use separate > workspaces, and would additionally mean we'd have to keep the > concept of 'variant' around instead of getting rid of it and > wouldn't be able to have the separation cleanly mirrored in > every aspect from project names (in the vars/projects/ and about the vars, the same would actually apply to those changes (first patch), I simply replied to this one only, I probably should have replied to that one too... > host_vars/*/ sense) to Jenkins job names. I didn't realize this about Jenkins until you pointed it out. So, since for Jenkins both mingw variants are separate entities/jobs, it now makes more sense to me to favour consistency and split them. Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
