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

[Andrea Bolognani]

On Tue, 2018-05-08 at 14:37 +0100, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>  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.

-- 
Andrea Bolognani / Red Hat / Virtualization