[Libvir] Please check my autoconf libvirt.m4
Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number. If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great. 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
Richard W.M. Jones wrote:
Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number.
If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great.
I should add that I use it like this: dnl Check for libvirt, sets LIBVIRT_VERSION. AC_LIBVIRT dnl Libvirt must be >= 0.2.1 AC_MSG_CHECKING([libvirt >= 0.2.1]) if test $LIBVIRT_VERSION -ge 2001; then AC_MSG_RESULT([ok]) else AC_MSG_ERROR([please upgrade your libvirt library]) fi 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 Wed, May 23, 2007 at 06:31:19PM +0100, Richard W.M. Jones wrote:
Richard W.M. Jones wrote:
Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number.
If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great.
I should add that I use it like this:
dnl Check for libvirt, sets LIBVIRT_VERSION. AC_LIBVIRT
dnl Libvirt must be >= 0.2.1 AC_MSG_CHECKING([libvirt >= 0.2.1]) if test $LIBVIRT_VERSION -ge 2001; then AC_MSG_RESULT([ok]) else AC_MSG_ERROR([please upgrade your libvirt library]) fi
I don't see that this buys us much over just doing PKG_CHECK_MODULES(LIBVIRT, libvirt >= 0.2.1) AC_SUBST(LIBVIRT_CFLAGS) AC_SUBST(LIBVIRT_LIBS) which already works... 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 -=|
Daniel P. Berrange wrote:
On Wed, May 23, 2007 at 06:31:19PM +0100, Richard W.M. Jones wrote:
Richard W.M. Jones wrote:
Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number.
If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great. I should add that I use it like this:
dnl Check for libvirt, sets LIBVIRT_VERSION. AC_LIBVIRT
dnl Libvirt must be >= 0.2.1 AC_MSG_CHECKING([libvirt >= 0.2.1]) if test $LIBVIRT_VERSION -ge 2001; then AC_MSG_RESULT([ok]) else AC_MSG_ERROR([please upgrade your libvirt library]) fi
I don't see that this buys us much over just doing
PKG_CHECK_MODULES(LIBVIRT, libvirt >= 0.2.1) AC_SUBST(LIBVIRT_CFLAGS) AC_SUBST(LIBVIRT_LIBS)
which already works...
Hmmm. pkg-config doesn't work with packages installed in non-standard places. (In fact for me the use of PKG_CHECK_MODULES in configure.in prevents me from installing on Debian at all, but that's possibly another story). However the real reason I went down this route was to check for the libvirt-python bindings ... See the bottom of the attached file. 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 Wed, May 23, 2007 at 07:13:05PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
On Wed, May 23, 2007 at 06:31:19PM +0100, Richard W.M. Jones wrote:
Richard W.M. Jones wrote:
Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number.
If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great. I should add that I use it like this:
dnl Check for libvirt, sets LIBVIRT_VERSION. AC_LIBVIRT
dnl Libvirt must be >= 0.2.1 AC_MSG_CHECKING([libvirt >= 0.2.1]) if test $LIBVIRT_VERSION -ge 2001; then AC_MSG_RESULT([ok]) else AC_MSG_ERROR([please upgrade your libvirt library]) fi
I don't see that this buys us much over just doing
PKG_CHECK_MODULES(LIBVIRT, libvirt >= 0.2.1) AC_SUBST(LIBVIRT_CFLAGS) AC_SUBST(LIBVIRT_LIBS)
which already works...
Hmmm. pkg-config doesn't work with packages installed in non-standard places.
Sure it does, just tell it what other prefixes you install stuff into, eg export PKG_CONFIG_PATH=$HOME/usr/lib/pkg-config
(In fact for me the use of PKG_CHECK_MODULES in configure.in prevents me from installing on Debian at all, but that's possibly another story).
Broken debian pkg-config install ? Pretty much all libraries are switching to use of pkg-config these days precisely because it allows all of the million variations of per-library custom autoconf crack to be removed. Anything which removes use of m4 is a good idea :-) 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 -=|
"Richard W.M. Jones" <rjones@redhat.com> wrote:
Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number.
If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great.
Hi Rich, In general, the autoconf "way" is to perform feature tests, rather than version-number comparison tests. The problem with the latter is that the invoking code can end up looking really obtuse, much like portable pre-autoconf #ifdef spaghetti C did. Also, if there's a way to do the test solely at compile- or link-time, that'd be good, since a run-test causes trouble when cross-compiling. With a library like libvirt, you might want to provide autoconf tests that detect "version X.Y or newer" by checking for some public symbol that was introduced in version X.Y, or maybe by a compile-check for a changed signature in a published header. If you really need the version of the library itself and can't rely on pkg-config (not everyone has that, and it's not always spelled that way), then you might consider making libvirt publish a symbol like __libvirt_version_X_Y_Z. Then an autoconf macro could find the version number with just a few link tests. Of course, that won't help for versions that predate the addition of the first __libvirt_version_X_Y_Z symbol. Jim
Thanks Jim, Dan. Discussing this has clarified my thinking on this a lot. Originally I wanted to test whether a particular instance of libvirt had support for the remote driver. Since the drivers don't usually export symbols directly from the library, it seemed that what I needed was a version check function. In fact that's wrong: even later versions of libvirt could be compiled --without-FEATURE. The only way to do this reliably is to test for presence of drivers at runtime. virGetVersion allows me to do this for drivers. Having said that, I think AC_LIBVIRT_PYTHON could be a useful check for virt-manager. 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
Hi Rich, I'd stick with just using pkg-config to check for the library itself and using a runtime check for supported drivers. As for checking for the python module, I don't really think virt-manager wants to do this at build time since it's not actually a build dep. Personally I think I'd prefer an install time check for python modules rather than runtime checks, but it seems that runtime checking is the usual python way. Cheers, Mark.
participants (4)
-
Daniel P. Berrange -
Jim Meyering -
Mark McLoughlin -
Richard W.M. Jones