[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_TRY_CPP/AC_CHECK_HEADER and --prefix != /usr/local
From: |
Bob Proulx |
Subject: |
Re: AC_TRY_CPP/AC_CHECK_HEADER and --prefix != /usr/local |
Date: |
Sat, 19 Oct 2002 11:40:15 -0600 |
User-agent: |
Mutt/1.4i |
Duncan Gibson <address@hidden> [2002-10-17 11:57:21 +0200]:
> Is there any reason why the includedir related to a user-supplied --prefix
> (i.e. not /usr/local) isn't automatically added to the CPPFLAGS or internal
> search path when looking for header files?
The --prefix is for an installation path and not a compilation path.
Those two concepts are not and should not be related.
> I installed fltk-1.1.0 with --prefix=/scratch/duncan
>
> I'm trying to create a configure.in for my own application, also to be
> installed under /scratch/duncan. However if I use
>
> AC_TRY_CPP([#include <FL/Fl.H>],...)
> or AC_CHECK_HEADER([FL/Fl.H],...)
> or AC_CHECK_HEADERS([FL/Fl.H],...)
>
> the configuration step fails, even if I set --prefix=/scratch/duncan
Are those header files part of your current project? Or part of a
different project that you had installed previously?
It seems strange to me that you would build with header files being
optional when you are building from your own directory. Why wouldn't
it be better to fail if you can't find an include file so that it
reminds you that you need to install it? Or perhaps it would be
better to configure a subsystem which can be enabled or disabled in a
large chunk with a command line option. But this is just my poor
understanding of your project talking.
> So far the only way round this is to set CPPFLAGS explicitly before
> checking for the header file.
>
> Is there a cleaner way?
If part of your current project that you are building now to install
then specify the path to the includes in your Makefile, assuming
automake in your Makefile.am. Example:
INCLUDES = -I$(top_srcdir)/lib -I$(top_srcdir)
If part of another project that was installed previously then you will
have to admit that /scratch/duncan is a nonstandard place to look for
header files. Therefore you will need to tell configure that you want
it to look for files in a nonstandard location. Here is some snippets
from the --help output of configure.
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CPP C preprocessor
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
Therefore setting CPPFLAGS is the desired method of indicating
nonstandard locations for included header files.
Note that I am not an autoconf maintainer. But having a separation
between installation and compilation is important and I was compelled
to speak about it. A project I worked on previously confused that
issue and created an endless amount of self inflicted problems.
Bob
pgpPdqYLodyhb.pgp
Description: PGP signature