Hi -
I am new to autoconf - the usual caveats and apologies apply ...
I am writing configure.ac templates for a number of related libraries
and executables. Most users will not be installing these in the usual
directories, i.e., typical configuration will be:
configure --prefix=/some/strange
Alexandre Duret-Lutz wrote:
> John> I've tried:
> John> AC_INIT(libspec, 1.0, [EMAIL PROTECTED])
> John> CPPFLAGS="-I$includedir $CPPFLAGS"
> John> LDFLAGS="-L$libdir $LDFLAGS"
> John> ...
> John> but this doesn't quite work - ac_cpp and friends end up with an
> John> unexpanded ${prefix
Hello -
I find it unsettling to have duplicate (at best) versions of things like
config.guess, config.sub, and install-sh in multiple CVS archives, so I
would like to have my "make dist" copy them in, preferably using the
autotools.
As far as I can tell, however, achieving this seems to presuppo
I have what I think is a style question:
If I want to do something with the results of autoconf tests in my
configure script, what's the best way to check these results? For
instance, say I'd like to do this:
AC_CHECK_LIB(norman, snStackPush)
AC_CHECK_HEADERS([norman.h])
# Gripe if neith
Lars Hecking:
> The names are fairly obvious, and there's a section in the autoconf manual
> that explains them (Results of Tests->Caching Results->Cache Variable Names).
Thomas Dickey:
> Though the mechanism is (has been) documented, the convention for several
> macros has changed a couple of
Last week I wrote:
> I have a question about sub-configuration and --enable switches. I
> would like a particular --enable switch to always be passed to the
> recursive configure scripts just like "precious" variables are.
I just discovered that precious variables don't do this either, so I
hav
Bruce Korb wrote:
> Use a common cache. See the snprintfv (sub)configury in:
>
> http://prdownloads.sf.net/autogen/autogen-5.3.8.tar.gz
The common cache is a good suggestion, although I'd rather not rely on my
users to do that. I couldn't tell if your autogen pointer was intended to be
an e
Maurice Turcotte wrote:
> Yes, I have looked at config.log.
>
> It says "checking for ioctl.h" but
> it doesn't say where it is checking. Is it
> checking in /usr/include? Is it checking in
> /opt/toolchains? How do I find out?
Sorry for the delayed response.
As an example, looking at one o
