Re: conditional use of PKG_CHECK_MODULES, along with platforms that don't have pkg-config

[Eric Blake]

On 09/21/2010 11:15 AM, Pete Batard wrote:
> Hi,
>
> After reading from [1] & [2], it looks like the PKG_CHECK_MODULES()
> macro cannot be used in conditionals, unless you actually have
> pkg-config installed, as it unconditionally results in a pkg-config
> related AC_REQUIRE.
>
> I am however trying to create a configure.ac where PKG_CHECK_MODULES
> could be used on platforms that typically have it (Linux), while ignored
> on platforms that don't (MinGW).

Are you are trying to target development on these two machines (where 
both Linux and mingw users run autoreconf, and you don't want autoreconf 
to fail if PKG_CHECK_MODULES is used but pkg-config is not installed), 
or are you targeting the end-user (where as long as the code for 
PKG_CHECK_MODULES is never reached, it shouldn't matter if the end user 
doesn't have pkg-config installed)?

> What I'm trying to achieve then is
> something like:
>
> AC_MSG_CHECKING([operating system])
> case $host in
> *-linux*)
> AC_DEFINE(OS_LINUX, [], [Linux backend])

Insufficient m4 quoting.  Get in the habit of using proper quotation, so 
you can avoid subtle bugs later:

AC_DEFINE([OS_LINUX], [], [Linux backend])

> (...)
> PKG_CHECK_MODULES(UDEV, libudev)
> (...)
> ;;
> *-mingw*)
> AC_DEFINE(OS_WINDOWS, [], [Windows backend])
> (...use non pkg-config equivalent library...)
> ;;
> esac

The autoconf way is to prefer feature checks over system checks.  But 
PKG_CHECK_MODULES tends to be hard-coded; personally, I'm in the camp of 
developers that thinks you are actually better off not using 
PKG_CHECK_MODULES, even though I've worked on projects that use it.  Can 
you instead write your tests using AC_SEARCH_LIBS, to see if libudev is 
available (whether or not you are on Linux or mingw)?  In particular, 
the gnulib module havelib demonstrates a nice way to conditionally check 
for the existence of a library without locking yourself in to the 
hard-coded nature of pkg-config.

> Unless I'm missing something, what I read from [2] leads me to think
> that neither case nor AS_CASE can be used to prevent the pkg-config
> requirement, and indeed, I am getting an error with the above on MinGW.

Using AS_CASE means that anything required by PKG_CHECK_MODULES will be 
floated before the AS_CASE begins, and executed unconditionally even if 
the case statement does not hit the branch that uses PKG_CHECK_MODULES. 
Using raw case means that the requirement will be floated only before 
the PKG_CHECK_MODULES, unless your entire case statement is called from 
inside another AC_DEFUN'd macro, in which case the required parts are 
floated prior to the beginning of the outer macro overall.

Not being entirely familiar with the guts of PKG_CHECK_MODULES, what 
exactly is it doing wrong on mingw that you are trying to avoid?

> This means that, the only possibility would be to either make pkg-config
> a requirement for all platforms (inconvenient for users) or not use
> PKG_CHECK_MODULES on platforms that have it.

If your problem is only one at autoreconf (that is, you are targeting 
mingw development), you are free to ship additional m4 files in your 
tarball, including the pkg-config.m4 file from pkg-config.  True, that 
means that you are introducing a potential version skew issue if your 
package bundled an older version of that file than what would be on the 
developer's machine when pkg-config is installed, but it means that the 
macro is always available for developers.

But if your problem is one of end users, I don't see why it makes much 
sense for your package to have a mandatory dependence on pkg-config on 
Linux but no dependence on mingw - to me, either the dependency should 
be there for both platforms, or avoided for both platforms.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org