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