[libvirt] [PATCH jenkins-ci 1/2] Enable mingw build for libvirt-glib project

[Andrea Bolognani]

On Fri, 2018-04-13 at 13:20 +0100, Daniel P. Berrangé wrote:
> On Fri, Apr 13, 2018 at 02:17:45PM +0200, Andrea Bolognani wrote:
> > On Thu, 2018-04-12 at 15:28 +0100, Daniel P. Berrangé wrote:
> > >    - gtk-doc
> > >    - intltool
> > >    - libxml2
> > > +  - mingw32-glib2
> > > +  - mingw64-glib2
> > >    - vala
> > 
> > You're missing a lot of packages here, probably because they are
> > already used for the libvirt MinGW build and you didn't reset your
> > test machine between builds, thus masking the issue.
> 
> No I didn't miss them, I only listed stuff that's unique to
> libvirt-glib - duplicating everything used by libvirt mingw
> builds, under libvirt-glib mingw builds is not required, as
> they're already present, and most are not even used by
> libvirt-glib

Hm, I guess I see where you're coming from.

One of the original ideas was that the dependencies listed here
would be as comprehensive as possible, so that you would be able
to skip building some parts of the stack (and installing the
corresponding build dependencies) if you were only interested in
higher-level projects such as virt-manager: in that case, you
would just install libvirt-python from the vendor repositories
and go ahead with your day.

I guess we haven't been very consistent with that, though, as
clearly shown by the fact that the list of requirements I offered
for the MinGW build is way bigger than that of the native build!

It's also unclear how useful being so strict about packages is,
and how realistic it is that we will get it right all of the
time :)

So perhaps a reasonable compromise is indeed not to list packages
again if one of the direct dependencies already needs them to
build: libvirt-glib would only list packages libvirt doesn't
already depend on, but there could be duplicates between libvirt
and libosinfo because neither depends on the other. That would
be much easier to get right.

tl;dr go ahead with your version of the patch, and I might have
      some other cleaning up to do later :)

-- 
Andrea Bolognani / Red Hat / Virtualization