[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_TRY_CPP/AC_CHECK_HEADER and --prefix != /usr/local
From: |
Duncan Gibson |
Subject: |
Re: AC_TRY_CPP/AC_CHECK_HEADER and --prefix != /usr/local |
Date: |
Mon, 28 Oct 2002 15:12:33 +0100 |
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.