[PATCH V2] configure.ac: Fallback to older detection code if pkg-config can't find expat

[Peter Hutterer]

On Mon, Feb 02, 2015 at 06:33:49PM -0800, Bill Spitzak wrote:
> 
> 
> On 02/02/2015 03:12 PM, sardemff7+wayland at sardemff7.net wrote:
> >On 2015-02-02 22:29, Bill Spitzak wrote:
> >>This paritally reverts commit a4afd90f9f0c27ed5f3f313b915c260673f8be34.
> >>
> >>On older expat versions (ie the one on Ubuntu 12.04) there is no
> >>pkg-config
> >>file, so fall back to the previous test for the header file when it
> >>fails.
> >>Test is slightly cleaned up from previous one.
> >>
> >>I could not use AC_SEARCH_LIBS as was suggested, as this leaves the
> >>switch
> >>in LIBS, not EXPAT_LIBS, and thus does not match the pkg-config results.
> >
> >Well, you can perfectly do that, especially since AC_CHECK_LIB does not
> >export EXPAT_LIBS either.
> 
> I think I may need some expert autotools help. I was basing these changes on
> looking at what got put into the config.h and Makefile. If I used
> AC_SEARCH_LIBS it added "-lexpat" to LIBS. I could make it also add it to
> EXPAT_LIBS but I could not figure out a way to stop it from being added to
> LIBS.

the usual process is (used to be?):
SAVE_LIBS="$LIBS"
AC_SEARCH_LIBS(....)
EXPAT_LIBS="$LIBS"
LIBS="$SAVE_LIBS"

so you save the current state and restore it after it got mangled. we do
that for the rdp compositro CPPFLAGS already for example.

> >I would advice to use AM_SUBST_NOTMAKE(LIBS) and never rely on LIBS at
> >all. But that could be left to another patch I guess.
> 
> Unfortunately it looks like Makefile.in uses $(LIBS) a lot and they would
> all have to be fixed. I found plenty of examples on the web for avoiding my
> problem by clearing LIBS after running AC_SEARCH_LIBS but that would break
> all the existing configuration.

note that Makefile.in is generated, you only need to care about Makefile.am

> >>  configure.ac |    7 ++++++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/configure.ac b/configure.ac
> >>index 0426b53..fc5ea55 100644
> >>--- a/configure.ac
> >>+++ b/configure.ac
> >>@@ -85,7 +85,12 @@ AC_ARG_WITH(icondir, [  --with-icondir=<dir>
> >>Look for cursor icons here],
> >>  AC_SUBST([ICONDIR])
> >>
> >>  if test "x$enable_scanner" = "xyes"; then
> >>-    PKG_CHECK_MODULES(EXPAT, [expat])
> >>+    PKG_CHECK_MODULES(EXPAT, [expat],,
> >>+        [AC_CHECK_HEADERS(expat.h,,
> >>+            [AC_MSG_ERROR([Can't find expat.h. Please install expat.])])
> >>+        AC_CHECK_LIB(expat, XML_ParserCreate, [EXPAT_LIBS="-lexpat"],
> >
> >Do you rely on PKG_CHECK_MODULES to AC_SUBST?
> 
> I have no idea. I'm trying not to change the behavior when PKG_CHECK_MODULES
> works, just to alter the behavior when it does not work.
> 
> I am not very clear what AC_SUBST does, for EXPAT_LIBS it seems to work the
> same whether I use that command or not. I am wondering if I am running into
> a problem with caching using my previous results.
> 
> I guess I could use some help with this to get the replacement correct...

usually you need to call AC_SUBST to get anything set in configure.ac into
the Makefile.am. so e.g.
FOO="some value"
AC_SUBST([FOO])

means you can now use $FOO in your Makefile.am. For manual dependencies
you'd do 
AC_SUBST([FOO_LIBS])
AC_SUBST([FOO_CFLAGS])
after setting the two, sort-of like you did above.

PKG_CHECK_MODULES does this for you, it subst's the _LIBS and CFLAGS
variables from the first parameter, i.e. EXPAT_LIBS and EXPAT_CFLAGS in this
case. That's why you usually don't see the subst calls when pkgconfig is
used. Not sure it does it when it can't find the package though, so in this
case you'll have to call it manually to make sure it's invoked regardless of
PKG_CHECK_MODULES' success.

Cheers,
   Peter