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