Re: AC_PATH_PROG and searching for regular files

[Benoit Sigoure <tsuna@xxxxxxxxxxxxx>]

On Nov 12, 2007, at 6:52 AM, Brian Dessent wrote:

> John Borchardt wrote:
>
> > AC_CHECK_LIB (library, function, [action-if-found],
> > [action-if-not-found], [other-libraries])
> > AC_CHECK_HEADER (header-file, [action-if-found],
> > [action-if-not-found], [includes = `default-includes'])
> >
> > it isn't clear to me how I can use these functions to get the  
> > location
> > of the library or header file.
>
> What those macros simulate is what would happen if you tried to link a
> program that uses the specified library (or compile an object that  
> uses
> the specified header), given the current setting of the variables CC,
> CXX, CPPFLAGS, CXXFLAGS, CFLAGS, LIBS, LDFLAGS, etc.  That is  
> precisely
> what you want to test, since that is exactly what you are trying to
> ensure will work.  In other words, if the test fails then you know
> something is wrong, because the test is meant to simulate what will
> happen in the Makefile shortly.  Generally you shouldn't really care
> about the actual location where the thing is found, just that the
> current setting of those variables is correct.
>
> If you are trying to support the case where headers and libs might  
> be in
> some nonstandard location, then there are generally two methods to
> handle that:
>
> A) The user is instructed to set the variables correctly, when  
> invoking
> configure, e.g.
>
> path/to/configure CPPFLAGS=-I/some/path/include \
>        LDFLAGS=-L/some/path/lib
>
> This is not really any kind of special case because in fact any
> well-behaved autoconf package should allow for all of these variables
> being set by the user.
>
> B) You add an AC_ARG_WITH that looks for "--with-foobar=/some/ 
> path", and
> prepends -I/some/path/include to CPPFLAGS and -L/some/path/lib to
> LDFLAGS before running the check tests.  This is just automating the
> above.
>
> If you want to bake in a list of possible locations to search, then  
> you
> code a loop that saves the current setting of the *FLAGS, prepends the
> test argument, runs a compile or link check, and loops if it failed.
>
> > I'm just trying to check for the files
> > existence, not necessarily link against it or anything.
>
> That's not the autoconf philosophy.  Again, you really shouldn't care
> what the actual location is, you should care that all of the relevant
> variables are set so that the test compile or test link succeeds.   
> This
> ensures that the library is usable (e.g. on multi-arch systems that it
> is finding the right flavor) and it allows for maximum user  
> flexibility
> since they can completely control what's happening by the setting of
> those variables.

Yes, that's exactly it.  If you want to have a look at a complete  
example, I wrote a set of macros to handle Boost that contains some  
automated-patch search if the user didn't give us the path to Boost,  
it's here:
http://repo.or.cz/w/boost.m4.git?a=blob;f=build-aux/boost.m4;hb=HEAD

Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf