Re: AC_TRY_CPP/AC_CHECK_HEADER and --prefix != /usr/local

[Duncan Gibson]

Apologies for not replying sooner: I've been away for a week.

Duncan Gibson asked:
DG> Is there any reason why the includedir related to a user-supplied
DG> --prefix (i.e. not /usr/local) isn't automatically added to the
DG> CPPFLAGS or internal search path when looking for header files?

Bob Proulx replied:
BP> The --prefix is for an installation path and not a compilation path.
BP> Those two concepts are not and should not be related.

Aha! This isn't obvious from the documentation.


DG> I installed fltk-1.1.0 with --prefix=/scratch/duncan

Surprising as this may seem, I'm working on a Linux box for which I
don't have root access. Therefore I can't install/update packages in
the usual /usr/local, but I can install under a scratch area.


DG> I'm trying to create a configure.in for my own application, also to
DG> be installed under /scratch/duncan. However if I use
DG>     AC_TRY_CPP([#include <FL/Fl.H>],...)
DG> or  AC_CHECK_HEADER([FL/Fl.H],...)
DG> or  AC_CHECK_HEADERS([FL/Fl.H],...)
DG> the configuration step fails, even if I set --prefix=/scratch/duncan

BP> Are those header files part of your current project?  Or part of a
BP> different project that you had installed previously?

No, these aren't part of my own code, but part of a toolkit which an
end-user may or may not have installed. I want to be able to offer a
basic ascii-only, console type version of my application as standard,
and to build a fancier GUI if fltk is installed on the end-user's box.


BP> It seems strange to me that you would build with header files being
BP> optional when you are building from your own directory.  Why wouldn't
BP> it be better to fail if you can't find an include file so that it
BP> reminds you that you need to install it?  Or perhaps it would be
BP> better to configure a subsystem which can be enabled or disabled in a
BP> large chunk with a command line option.  But this is just my poor
BP> understanding of your project talking.

See above. I want to offer various levels of my application: (a) ascii
only, (b) GUI version built with fltk, (c) GUI + OpenGL graphics, etc.
It was while I was working out how to enable or disable building such
additional layers that came across this apparent problem where the
include search path doesn't include directories "implied" by --prefix.

Since this is only an apparent problem, and not a real problem, the
worthwhile information which you supply below is "incidental".

Cheers
Duncan


DG> So far the only way round this is to set CPPFLAGS explicitly before
DG> checking for the header file.  Is there a cleaner way?

BP> If part of your current project that you are building now to install
BP> then specify the path to the includes in your Makefile, assuming
BP> automake in your Makefile.am.  Example:

BP>   INCLUDES = -I$(top_srcdir)/lib -I$(top_srcdir)

BP> If part of another project that was installed previously then you
BP> will have to admit that /scratch/duncan is a nonstandard place to
BP> look for header files.  Therefore you will need to tell configure
BP> that you want it to look for files in a nonstandard location. Here
BP> is some snippets from the --help output of configure.

BP>   Some influential environment variables:
BP>     CC          C compiler command
BP>     CFLAGS      C compiler flags
BP>     LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries
BP>                 in a nonstandard directory <lib dir>
BP>     CPPFLAGS    C/C++ preprocessor flags, e.g. -I<include dir> if you
BP>                 have headers in a nonstandard directory <include dir>
BP>     CPP         C preprocessor

BP>   Use these variables to override the choices made by `configure' or
BP>   to help it to find libraries and programs with nonstandard
BP>   names/locations.

BP> Therefore setting CPPFLAGS is the desired method of indicating
BP> nonstandard locations for included header files.

BP> Note that I am not an autoconf maintainer.  But having a separation
BP> between installation and compilation is important and I was compelled
BP> to speak about it.  A project I worked on previously confused that
BP> issue and created an endless amount of self inflicted problems.