On Wed, May 09, 2018 at 01:34:53PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-05-08 at 14:37 +0100, Daniel P. Berrangé wrote:
> > Signed-off-by: Daniel P. Berrangé <berra...@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.
Opps, i blindly assumed it was already there for libvirt
>
> > 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.
Agreed - I looked back in history and it seems I added --enable-gtk-doc
to autogen.sh right at start when integrating gtk-doc. There's no good
reason given, and other projects work without this so lets remove it.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
