On Tue, 2018-05-08 at 14:37 +0100, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
> ---
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
