Re: [libvirt] [jenkins-ci PATCH] Build libosinfo and osinfo-db-tools on mingw platform

On Tue, 2018-05-08 at 14:37 +0100, Daniel P. Berrangé wrote: > Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com&gt; > --- > guests/host_vars/libvirt-fedora-rawhide/main.yml | 2 ++ > guests/vars/mappings.yml | 6 ++++++ > guests/vars/projects/libosinfo+mingw.yml | 8 ++++++++ > guests/vars/projects/osinfo-db-tools+mingw.yml | 10 ++++++++++ > projects/libosinfo.yaml | 12 ++++++++++++ > projects/osinfo-db-tools.yaml | 12 ++++++++++++ > 6 files changed, 50 insertions(+) > create mode 100644 guests/vars/projects/libosinfo+mingw.yml > create mode 100644 guests/vars/projects/osinfo-db-tools+mingw.yml I was wondering why we didn't do this just the other day... Thanks for looking into it before I had a chance to :) > diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml > index f1777fe..3e33bf1 100644 > --- a/guests/vars/mappings.yml > +++ b/guests/vars/mappings.yml > @@ -368,6 +368,9 @@ mappings: > mingw32-gtk-vnc2: > FedoraRawhide: mingw32-gtk-vnc2 > > + mingw32-libarchive: > + FedoraRawhide: mingw32-libarchive > + > mingw32-libgovirt: > FedoraRawhide: mingw32-libgovirt > > @@ -437,6 +440,9 @@ mappings: > mingw64-gtk-vnc2: > FedoraRawhide: mingw64-gtk-vnc2 > > + mingw64-libarchive: > + FedoraRawhide: mingw64-libarchive > + > mingw64-libgovirt: > FedoraRawhide: mingw64-libgovirt > You also need mingw32-libxslt: FedoraRawhide: mingw32-libxslt mingw64-libxslt: FedoraRawhide: mingw64-libxslt here.

> diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml > index 0d25447..8e3d105 100644 > --- a/projects/libosinfo.yaml > +++ b/projects/libosinfo.yaml > @@ -13,3 +13,15 @@ > - autotools-rpm-job: > parent_jobs: 'libosinfo-master-check' > machines: '{rpm_machines}' > + - autotools-build-job: > + parent_jobs: 'osinfo-db-tools-master-build-mingw32' > + variant: -mingw32 > + local_env: '{mingw32_local_env}' > + autogen_args: '{mingw32_autogen_args}' > + machines: '{mingw_machines}' > + - autotools-build-job: > + parent_jobs: 'osinfo-db-tools-master-build-mingw64' > + variant: -mingw64 > + local_env: '{mingw64_local_env}' > + autogen_args: '{mingw64_autogen_args}' > + machines: '{mingw_machines}' Unfortunately, this doesn't quite work: [...] checking for gtk-doc... no configure: WARNING: You will not be able to create source packages with 'make dist' because gtk-doc >= 1.10 is not found. checking for gtkdoc-check... gtkdoc-check.test checking for gtkdoc-check... /usr/bin/gtkdoc-check checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf checking whether to build gtk-doc documentation... yes configure: error: You must have gtk-doc >= 1.10 installed to build documentation for libosinfo. Please install gtk-doc or disable building the documentation by adding '--disable-gtk-doc' to './configure'. The problem is that we override both $PKG_CONFIG_PATH and $PKG_CONFIG_LIBDIR in {mingw*_local_env}, which causes pkg-config to only look for .pc files in MinGW's directories; on the other hand, the GTK_DOC_CHECK() macro also uses pkg-config to decide whether gtk-doc is available, and due to the overrides it can't locate the native .pc file and decides it's not there. The only reason we didn't run into this issue when enabling MinGW builds for libvirt-glib, which also uses gtk-doc, is that that project's autogen.sh doesn't explicitly enable gtk-doc support, while libosinfo's does: . gnome-autogen.sh --enable-gtk-doc "$@" I can see a few ways to address this: 1) make it so $PKG_CONFIG_PATH or $PKG_CONFIG_LIBDIR include the native pkg-config directories even when performing MinGW builds; 2) add --disable-gtk-doc or --enable-gtk-doc=check to {mingw*_autogen_args}, thus overriding the default hardcoded in libosinfo's autogen.sh; 3) change libosinfo's autogen.sh not to mandate gtk-doc for all builds. Option 3) looks like the best one to me, mostly because I think the default behavior of checking for gtk-doc's presence and decide whether to build the API reference based on that is more sane than forcing gtk-doc to be present; moreover, --enable-gtk-doc is already in $DISTCHECK_CONFIGURE_FLAGS and prepare-release.sh, so there's no risk of accidentally generating a release that doesn't contain the API reference.