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.
