[Libvir] PATCH 0/5: Rework the configure script
The following series of patches re-work the configure to solve a number of issues. I'll describe each one alongside its respective patch... Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like $ make cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run aclocal-1.9 -I m4 cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run automake-1.9 --gnu cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run autoconf configure.in:268: error: possibly undefined macro: PKG_CONFIG_ENABLED If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. This is due to this bit of configure where we reference an env variable which doesn't exist: if test "z$with_libxml" = "zno" ; then AC_MSG_CHECKING(for libxml2 libraries >= $LIBXML_MIN_VERSION) AC_MSG_ERROR(libxml2 >= $LIBXML_MIN_VERSION is required for $XMLSEC_PACKAGE) elif test "z$with_libxml" = "z" -a "z$PKG_CONFIG_ENABLED" = "zyes" ; then PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= $LIBXML_MIN_VERSION, [LIBXML_FOUND=yes], [LIBXML_FOUND=no]) fi The whole test for libxml is overly complex and can be reduced to a single call to PKG_CHECK_MODULES. There is no need to have special configure script --with_libxml args to override the location, since pkg-config already gives you two ways todo that - either use PKG_CONFIG_PATH to point to your alternative install, or use LIBXML_CFLAGS and LIBXML_LIBS env vars to set the explicitly flags. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 02:29:50AM +0100, Daniel P. Berrange wrote:
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like
$ make cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run aclocal-1.9 -I m4 cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run automake-1.9 --gnu cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run autoconf configure.in:268: error: possibly undefined macro: PKG_CONFIG_ENABLED If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
This is due to this bit of configure where we reference an env variable which doesn't exist:
if test "z$with_libxml" = "zno" ; then AC_MSG_CHECKING(for libxml2 libraries >= $LIBXML_MIN_VERSION) AC_MSG_ERROR(libxml2 >= $LIBXML_MIN_VERSION is required for $XMLSEC_PACKAGE) elif test "z$with_libxml" = "z" -a "z$PKG_CONFIG_ENABLED" = "zyes" ; then PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= $LIBXML_MIN_VERSION, [LIBXML_FOUND=yes], [LIBXML_FOUND=no]) fi
The whole test for libxml is overly complex and can be reduced to a single call to PKG_CHECK_MODULES. There is no need to have special configure script --with_libxml args to override the location, since pkg-config already gives you two ways todo that - either use PKG_CONFIG_PATH to point to your alternative install, or use LIBXML_CFLAGS and LIBXML_LIBS env vars to set the explicitly flags.
IMHO this severely reduces the set of OSes where configure will wok as a result. Not everything ships with all libraries registered with pkg-config. I would like to hear what the non-Linux users think. xml2-config is part of libxml2 distribution, pkg-config is not, so the pkg-config check will work only if the OS integration decided to make it work. To me the goal of configure is to get maximum portability (otherwise honnestly, why bother with the auto*, right ?) In the case of libvirt though we may conclude that we target only OSes where pkg-config is set up, could someone clarify to me the status of pkg-config (at least for libxml2) on: - Solaris (I guess yes) - OS-X - cygwin The alternative is to fix the configure.in script, maybe that's the right approach, maybe it's not worth it. I can't tell but I would like to make sure we don't break the detection on at least the 3 mentionned platforms. And I know it does work now, since xmlsec is ported to those. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Sep 18, 2007 at 03:32:35AM -0400, Daniel Veillard wrote:
On Tue, Sep 18, 2007 at 02:29:50AM +0100, Daniel P. Berrange wrote:
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like
$ make cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run aclocal-1.9 -I m4 cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run automake-1.9 --gnu cd . && /bin/sh /home/berrange/src/xen/libvirt/missing --run autoconf configure.in:268: error: possibly undefined macro: PKG_CONFIG_ENABLED If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
This is due to this bit of configure where we reference an env variable which doesn't exist:
if test "z$with_libxml" = "zno" ; then AC_MSG_CHECKING(for libxml2 libraries >= $LIBXML_MIN_VERSION) AC_MSG_ERROR(libxml2 >= $LIBXML_MIN_VERSION is required for $XMLSEC_PACKAGE) elif test "z$with_libxml" = "z" -a "z$PKG_CONFIG_ENABLED" = "zyes" ; then PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= $LIBXML_MIN_VERSION, [LIBXML_FOUND=yes], [LIBXML_FOUND=no]) fi
The whole test for libxml is overly complex and can be reduced to a single call to PKG_CHECK_MODULES. There is no need to have special configure script --with_libxml args to override the location, since pkg-config already gives you two ways todo that - either use PKG_CONFIG_PATH to point to your alternative install, or use LIBXML_CFLAGS and LIBXML_LIBS env vars to set the explicitly flags.
IMHO this severely reduces the set of OSes where configure will wok as a result. Not everything ships with all libraries registered with pkg-config. I would like to hear what the non-Linux users think. xml2-config is part of libxml2 distribution, pkg-config is not, so the pkg-config check will work only if the OS integration decided to make it work. To me the goal of configure is to get maximum portability (otherwise honnestly, why bother with the auto*, right ?)
pkg-config is trivial to install on any common OS & is widely used by all modern libraries. The whole point is to increase portability & reliability of package configuration and give developers a standard way to override what versions of an library you build against. Only having to worry about pkg-config, instead of a multitude of different library specific XXX-config scripts is a more pleasant proposition. It also increases the clarity of the configure scripts.
In the case of libvirt though we may conclude that we target only OSes where pkg-config is set up, could someone clarify to me the status of pkg-config (at least for libxml2) on: - Solaris (I guess yes) - OS-X - cygwin
http://pkg-config.freedesktop.org/wiki/ "pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library" Any recent library is using pkg-config for build integration - we provide a pkgconfig script ourselves in libvirt. It is the defacto standard as can be seen from the listof pkg-config files installed even on FC6.... alsa.pc libgsf-gnome-1.pc aspell.pc libgtop-2.0.pc atk.pc libgvc.pc audiofile.pc libIDL-2.0.pc bigreqsproto.pc libidn.pc blkid.pc libloginhelper-1.0.pc bonobo-activation-2.0.pc libmetacity-private.pc cairo-ft.pc libnfsidmap.pc cairo.pc libnm-util.pc cairo-pdf.pc libpanelapplet-2.0.pc cairo-png.pc libpathplan.pc cairo-ps.pc libpng12.pc cairo-svg.pc libpng.pc cairo-xlib.pc librpcsecgss.pc cairo-xlib-xrender.pc librsvg-2.0.pc com_err.pc libspi-1.0.pc compositeproto.pc libssl.pc cspi-1.0.pc libstartup-notification-1.0.pc damageproto.pc libstatgrab.pc dbus-1.pc libuser.pc dbus-glib-1.pc libvirt.pc devmapper.pc libwnck-1.0.pc dmxproto.pc libxml-2.0.pc e2p.pc libxslt.pc eel-2.0.pc loudmouth-1.0.pc esound.pc neon.pc evieproto.pc NetworkManager.pc ext2fs.pc nspr.pc firefox-gtkmozembed.pc nss.pc firefox-js.pc ogg.pc firefox-plugin.pc openssl.pc firefox-xpcom.pc ORBit-2.0.pc fixesproto.pc ORBit-CosNaming-2.0.pc fontcacheproto.pc ORBit-idl-2.0.pc fontconfig.pc ORBit-imodule-2.0.pc fontenc.pc pangocairo.pc fontsproto.pc pangoft2.pc fontutil.pc pango.pc freetype2.pc pangoxft.pc gail.pc pangox.pc gconf-2.0.pc pycairo.pc gdk-2.0.pc pygobject-2.0.pc gdk-pixbuf-2.0.pc pygtk-2.0.pc gdk-pixbuf-xlib-2.0.pc randrproto.pc gdk-x11-2.0.pc recordproto.pc gdlib.pc renderproto.pc glib-2.0.pc resourceproto.pc glproto.pc scrnsaverproto.pc gmime-sharp.pc sdl.pc gmodule-2.0.pc shared-mime-info.pc gmodule-export-2.0.pc sm.pc gmodule-no-export-2.0.pc sqlite3.pc gnet-2.0.pc ss.pc gnome-desktop-2.0.pc tomboy-plugins.pc gnome-keyring-1.pc trapproto.pc gnome-mime-data-2.0.pc uuid.pc gnome-pilot-2.0.pc valgrind.pc gnome-python-desktop-2.0.pc videoproto.pc gnome-python-extras-2.0.pc vorbisenc.pc gnome-screensaver.pc vorbisfile.pc gnome-settings-daemon.pc vorbis.pc gnome-vfs-2.0.pc vte.pc gnome-vfs-module-2.0.pc x11.pc gnome-window-settings-2.0.pc xau.pc gnutls-extra.pc xaw6.pc gnutls.pc xaw7.pc gobject-2.0.pc xcmiscproto.pc gswitchit.pc xcomposite.pc gthread-2.0.pc xcursor.pc gtk+-2.0.pc xdamage.pc gtk-engines-2.pc xdmcp.pc gtksourceview-1.0.pc xevie.pc gtk+-unix-print-2.0.pc xext.pc gtk-vnc-1.0.pc xextproto.pc gtk+-x11-2.0.pc xf86bigfontproto.pc gweather.pc xf86dgaproto.pc hal.pc xf86driproto.pc hal-storage.pc xf86miscproto.pc ice.pc xf86rushproto.pc inputproto.pc xf86vidmodeproto.pc kbproto.pc xfixes.pc libagraph.pc xfontcache.pc libart-2.0.pc xfont.pc libbonobo-2.0.pc xft.pc libbonoboui-2.0.pc xinerama.pc libcdt.pc xineramaproto.pc libcroco-0.6.pc xi.pc libcrypto.pc xmu.pc libcurl.pc xmuu.pc libdrm.pc xorg-server.pc libexslt.pc xpm.pc libgail-gnome.pc xproto.pc libgcj.pc xproxymngproto.pc libglade-2.0.pc xrandr.pc libgnome-2.0.pc xrender.pc Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 02:40:06PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 18, 2007 at 03:32:35AM -0400, Daniel Veillard wrote:
only if the OS integration decided to make it work. To me the goal of configure is to get maximum portability (otherwise honnestly, why bother with the auto*, right ?)
pkg-config is trivial to install on any common OS & is widely used by all modern libraries. The whole point is to increase portability & reliability
I don't want to require people to install it. I don't want people to have to reinstall libxml2 as a result too.
In the case of libvirt though we may conclude that we target only OSes where pkg-config is set up, could someone clarify to me the status of pkg-config (at least for libxml2) on: - Solaris (I guess yes) - OS-X - cygwin
http://pkg-config.freedesktop.org/wiki/
"pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library"
My question is not if it *works* on said platform, my question if it is installed by default on said platform. I don't want pkg-config to become a new requirement for libvirt just for cleaning up the configure file, sorry. And stating that we ship it in linux is of no interest, if I were okay with just linux I would have a simple Makefile which would be even cleaner and simple.
Any recent library is using pkg-config for build integration - we provide a
Not the question again. Assume I'm on an OS-X box, will configure find the libxml2 with the tweak for configure out of the box. that's the only thing that matters and sorry the cut and paste don't answer that. If someone with a configured Os-X and someone with a configured cygwin could answer then I would be okay if it's there by default. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Sep 18, 2007 at 03:32:35AM -0400, Daniel Veillard wrote:
In the case of libvirt though we may conclude that we target only OSes where pkg-config is set up, could someone clarify to me the status of pkg-config (at least for libxml2) on: - Solaris (I guess yes)
We have .pc files: /usr/lib/pkgconfig/libxml-2.0.pc /usr/lib/pkgconfig/libxslt.pc What else is changed to use pkgconfig here? Coverage is a little spotty in places (but we should fix that) regards john
On Tue, Sep 18, 2007 at 05:39:09PM +0100, John Levon wrote:
On Tue, Sep 18, 2007 at 03:32:35AM -0400, Daniel Veillard wrote:
In the case of libvirt though we may conclude that we target only OSes where pkg-config is set up, could someone clarify to me the status of pkg-config (at least for libxml2) on: - Solaris (I guess yes)
We have .pc files:
/usr/lib/pkgconfig/libxml-2.0.pc /usr/lib/pkgconfig/libxslt.pc
What else is changed to use pkgconfig here? Coverage is a little spotty in places (but we should fix that)
Of the series of patches I sent we'll have libxml, gnutls, avahi and PolicyKit. The latter two will simply be disabled if not found. We need to make it possible to disable gnutls too, but that's more extensive work that I've got time for just now. Following IRC discussions with Daniel I'm also revising my libxml patch so it will use pkg-config, but still fallback to xml-config Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 10:31:58PM +0100, Daniel P. Berrange wrote:
Of the series of patches I sent we'll have libxml, gnutls, avahi and PolicyKit.
We have pc files for the first two. The second two we're still looking at but I presume we'll be planning on .pc's for those too cheers john
On Tue, Sep 18, 2007 at 02:29:50AM +0100, Daniel P. Berrange wrote:
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like
Here is an alternative version which makes the pkg-config checks for libxml actually work, and still lets it fall back to xml-config if pkg-config is either not installed, or missing the .pc file. It also fixes the AC_MSG usage in the xml-config path so you get newlines in the right place. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Sep 19, 2007 at 12:30:18AM +0100, Daniel P. Berrange wrote:
On Tue, Sep 18, 2007 at 02:29:50AM +0100, Daniel P. Berrange wrote:
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like
Here is an alternative version which makes the pkg-config checks for libxml actually work, and still lets it fall back to xml-config if pkg-config is either not installed, or missing the .pc file. It also fixes the AC_MSG usage in the xml-config path so you get newlines in the right place.
Ignore that version. Here's a corrected one which applies against the current CVS tree. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Sep 19, 2007 at 03:31:50AM +0100, Daniel P. Berrange wrote:
On Wed, Sep 19, 2007 at 12:30:18AM +0100, Daniel P. Berrange wrote:
On Tue, Sep 18, 2007 at 02:29:50AM +0100, Daniel P. Berrange wrote:
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like
Here is an alternative version which makes the pkg-config checks for libxml actually work, and still lets it fall back to xml-config if pkg-config is either not installed, or missing the .pc file. It also fixes the AC_MSG usage in the xml-config path so you get newlines in the right place.
Ignore that version. Here's a corrected one which applies against the current CVS tree.
Thanks a lot for dealing with the grumpy old frenchman :-) Looks just fine to me +1 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Sep 19, 2007 at 04:27:03AM -0400, Daniel Veillard wrote:
On Wed, Sep 19, 2007 at 03:31:50AM +0100, Daniel P. Berrange wrote:
On Wed, Sep 19, 2007 at 12:30:18AM +0100, Daniel P. Berrange wrote:
On Tue, Sep 18, 2007 at 02:29:50AM +0100, Daniel P. Berrange wrote:
Currently if you have a configured working directory and you touch some file that would cause autoconf to re-run configure it'll crash & burn with an error like
Here is an alternative version which makes the pkg-config checks for libxml actually work, and still lets it fall back to xml-config if pkg-config is either not installed, or missing the .pc file. It also fixes the AC_MSG usage in the xml-config path so you get newlines in the right place.
Ignore that version. Here's a corrected one which applies against the current CVS tree.
Thanks a lot for dealing with the grumpy old frenchman :-) Looks just fine to me +1
Ok,comitted. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
The current GNU TLS tests in the configure script just use CHECK_HEADER and CHECK_LIB to try and locate gnutls. This is fine if its in /usr, but no so useful if it is installed elsewhere. There are also no Makefile.am vars set to let you specify an alternate install location. gnutls already comes with support for pkg-config, so this patch just switches our configure script and Makefiles over to use that. Building against a different GNU TLS install is now just a matter of setting PKG_CONFIG_PATH, or the GNUTLS_LIBS and GNUTLS_CFLAGS vars. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 02:32:59AM +0100, Daniel P. Berrange wrote:
The current GNU TLS tests in the configure script just use CHECK_HEADER and CHECK_LIB to try and locate gnutls. This is fine if its in /usr, but no so useful if it is installed elsewhere. There are also no Makefile.am vars set to let you specify an alternate install location. gnutls already comes with support for pkg-config, so this patch just switches our configure script and Makefiles over to use that. Building against a different GNU TLS install is now just a matter of setting PKG_CONFIG_PATH, or the GNUTLS_LIBS and GNUTLS_CFLAGS vars.
Same worry about pkg-config portability as for 1/5, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Sep 18, 2007 at 03:33:22AM -0400, Daniel Veillard wrote:
On Tue, Sep 18, 2007 at 02:32:59AM +0100, Daniel P. Berrange wrote:
The current GNU TLS tests in the configure script just use CHECK_HEADER and CHECK_LIB to try and locate gnutls. This is fine if its in /usr, but no so useful if it is installed elsewhere. There are also no Makefile.am vars set to let you specify an alternate install location. gnutls already comes with support for pkg-config, so this patch just switches our configure script and Makefiles over to use that. Building against a different GNU TLS install is now just a matter of setting PKG_CONFIG_PATH, or the GNUTLS_LIBS and GNUTLS_CFLAGS vars.
Same worry about pkg-config portability as for 1/5,
Here's an updated version which uses pkg-config by default, but if that's not present uses the existing logic for CHECK_LIB. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Sep 19, 2007 at 03:33:07AM +0100, Daniel P. Berrange wrote:
On Tue, Sep 18, 2007 at 03:33:22AM -0400, Daniel Veillard wrote:
On Tue, Sep 18, 2007 at 02:32:59AM +0100, Daniel P. Berrange wrote:
The current GNU TLS tests in the configure script just use CHECK_HEADER and CHECK_LIB to try and locate gnutls. This is fine if its in /usr, but no so useful if it is installed elsewhere. There are also no Makefile.am vars set to let you specify an alternate install location. gnutls already comes with support for pkg-config, so this patch just switches our configure script and Makefiles over to use that. Building against a different GNU TLS install is now just a matter of setting PKG_CONFIG_PATH, or the GNUTLS_LIBS and GNUTLS_CFLAGS vars.
Same worry about pkg-config portability as for 1/5,
Here's an updated version which uses pkg-config by default, but if that's not present uses the existing logic for CHECK_LIB.
Looks just fine too, thanks a lot ! +1 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Sep 19, 2007 at 04:28:48AM -0400, Daniel Veillard wrote:
On Wed, Sep 19, 2007 at 03:33:07AM +0100, Daniel P. Berrange wrote:
On Tue, Sep 18, 2007 at 03:33:22AM -0400, Daniel Veillard wrote:
On Tue, Sep 18, 2007 at 02:32:59AM +0100, Daniel P. Berrange wrote:
The current GNU TLS tests in the configure script just use CHECK_HEADER and CHECK_LIB to try and locate gnutls. This is fine if its in /usr, but no so useful if it is installed elsewhere. There are also no Makefile.am vars set to let you specify an alternate install location. gnutls already comes with support for pkg-config, so this patch just switches our configure script and Makefiles over to use that. Building against a different GNU TLS install is now just a matter of setting PKG_CONFIG_PATH, or the GNUTLS_LIBS and GNUTLS_CFLAGS vars.
Same worry about pkg-config portability as for 1/5,
Here's an updated version which uses pkg-config by default, but if that's not present uses the existing logic for CHECK_LIB.
Looks just fine too, thanks a lot !
Also comitted, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Watching the hundreds of lines of configure output to see if it detected a package correctly is painful. This patch adds a summary output at the end of the configure script.... configure: configure: Configuration summary configure: ===================== configure: configure: Drivers configure: configure: Xen: yes configure: QEMU: yes configure: OpenVZ: no configure: Test: yes configure: Remote: yes configure: configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 configure: gnutls: -I/home/berrange/usr/include -L/home/berrange/usr/lib -lgnutls configure: configure: Miscellaneous configure: configure: Debug: no configure: If you use --quiet to configure, it is omitted. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 02:35:05AM +0100, Daniel P. Berrange wrote:
Watching the hundreds of lines of configure output to see if it detected a package correctly is painful. This patch adds a summary output at the end of the configure script....
configure: configure: Configuration summary configure: ===================== configure: configure: Drivers configure: configure: Xen: yes configure: QEMU: yes configure: OpenVZ: no configure: Test: yes configure: Remote: yes configure: configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 configure: gnutls: -I/home/berrange/usr/include -L/home/berrange/usr/lib -lgnutls configure: configure: Miscellaneous configure: configure: Debug: no configure:
If you use --quiet to configure, it is omitted.
Very nice, +1 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Sep 18, 2007 at 02:35:05AM +0100, Daniel P. Berrange wrote:
Watching the hundreds of lines of configure output to see if it detected a package correctly is painful. This patch adds a summary output at the end of the configure script....
configure: configure: Configuration summary configure: ===================== configure: configure: Drivers configure: configure: Xen: yes configure: QEMU: yes configure: OpenVZ: no configure: Test: yes configure: Remote: yes configure: configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 configure: gnutls: -I/home/berrange/usr/include -L/home/berrange/usr/lib -lgnutls configure: configure: Miscellaneous configure: configure: Debug: no configure:
If you use --quiet to configure, it is omitted.
Very nice, +1
Daniel
+1 I also think this is very useful. Thanks Atsushi SAKAI
Daniel P. Berrange wrote:
Watching the hundreds of lines of configure output to see if it detected a package correctly is painful. This patch adds a summary output at the end of the configure script....
configure: configure: Configuration summary configure: ===================== configure: configure: Drivers configure: configure: Xen: yes configure: QEMU: yes configure: OpenVZ: no configure: Test: yes configure: Remote: yes configure: configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 configure: gnutls: -I/home/berrange/usr/include -L/home/berrange/usr/lib -lgnutls configure: configure: Miscellaneous configure: configure: Debug: no configure:
If you use --quiet to configure, it is omitted.
Yeah, +1 also. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Tue, Sep 18, 2007 at 04:01:58PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
Watching the hundreds of lines of configure output to see if it detected a package correctly is painful. This patch adds a summary output at the end of the configure script....
configure: configure: Configuration summary configure: ===================== configure: configure: Drivers configure: configure: Xen: yes configure: QEMU: yes configure: OpenVZ: no configure: Test: yes configure: Remote: yes configure: configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 configure: gnutls: -I/home/berrange/usr/include -L/home/berrange/usr/lib -lgnutls configure: configure: Miscellaneous configure: configure: Debug: no configure:
If you use --quiet to configure, it is omitted.
Yeah, +1 also.
Ok, committed. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 02:35:05AM +0100, Daniel P. Berrange wrote:
AC_HELP_STRING([--enable-debug=no/yes], - [enable debugging output])) + [enable debugging output]),[],[enable_debug=no])
Note, AC_HELP_STRING is deprecated in autoconf 2.59 and later, use AS_HELP_STRING.
if test x"$enable_debug" = x"yes"; then AC_DEFINE(ENABLE_DEBUG, [], [whether debugging is enabled]) fi @@ -190,35 +190,24 @@ WITH_XEN=0 WITH_XEN=0
if test "$with_openvz" = "yes" ; then
I see x"$value" somewhere only. Karel -- Karel Zak <kzak@redhat.com>
We previously added a --disable-stack-protector arg to explicitly disable the use of GCC's stack protector which is enabled when the FORTIFY_SOURCE flag is used. This is sub-optimal since the user will still get compile failures when running configure for first time, and if they're lucky will they find out about the precense of the --disable-stack-protector arg & infer what it might do. There were a couple of problems I identified - Even if giving --enable-compiler-warnings=no we would still set FORTIFY_SOURCE and related flags. - Our test for compiler flags only tried compiling, but not linking. The latter is what seemed to fail on Debian. The attached patch removes the --disable-stack-protector arg to configure, instead allowing use of --enable-compiler-warnings=no. It also makes sure to test linking with the desired flags, so that the default behaviour ought to work correctly. I'd appreciate someone with a Debian box verifying this theory... Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel P. Berrange wrote:
I'd appreciate someone with a Debian box verifying this theory...
Theory verified ... Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
You will hate me.. but: On Tue, Sep 18, 2007 at 02:40:19AM +0100, Daniel P. Berrange wrote:
- AC_TRY_COMPILE([], [], + AC_TRY_LINK([], [], has_option=yes, has_option=no,) CFLAGS="$SAVE_CFLAGS"
AC_TRY_COMPILE is obsolete, use AC_LINK_IFELSE (also AC_TRY_COMPILE --> AC_COMPILE_IFELSE) http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html Karel -- Karel Zak <kzak@redhat.com>
The configure script checks for linux/param.h linux/sockios.h linux/if_bridge.h linux/if_tun.h Even if compiling without the QEMU enabled. These are only used by the network driver, which is part of the QEMU driver, so checking for them when configure is given --disable-qemu is bogus Dan.. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Sep 18, 2007 at 02:42:14AM +0100, Daniel P. Berrange wrote:
The configure script checks for
linux/param.h linux/sockios.h linux/if_bridge.h linux/if_tun.h
Even if compiling without the QEMU enabled. These are only used by the network driver, which is part of the QEMU driver, so checking for them when configure is given --disable-qemu is bogus
Increases portability of the core, very good +1 ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Sep 18, 2007 at 03:35:39AM -0400, Daniel Veillard wrote:
On Tue, Sep 18, 2007 at 02:42:14AM +0100, Daniel P. Berrange wrote:
The configure script checks for
linux/param.h linux/sockios.h linux/if_bridge.h linux/if_tun.h
Even if compiling without the QEMU enabled. These are only used by the network driver, which is part of the QEMU driver, so checking for them when configure is given --disable-qemu is bogus
Increases portability of the core, very good +1 !
Committed Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (6)
-
Atsushi SAKAI -
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Karel Zak -
Richard W.M. Jones