Finding custom includes directories with autoconf

Question

I'm trying to compile a program which uses the festival library.

Basically, the requirements are that you include the festival and estools header directories in the include path, and you include both their library paths.

In a normal installation, they simply stay in their own folders, so you have

/some/path/festival/src/include 
/some/other/path/estools/include

as the required search path, and

/some/path/festival/src/lib
/some/other/path/estools/lib

as the library path.

I think that the proper way to handle this is with a "--with-estools" and a "--with-festival" configure option.

However, there's a different setup when it is installed on a debian/ubuntu system. I'd like to be able to handle this setup, where the search paths are

/usr/include/festival
/usr/include/estools

and the search path is just

/usr/lib

I'd like to detect the second case, and handle it automatically, while still requiring the user to specify the first two directories if the second case is not satisfied. How would I do this?

Answer 1

Is there something that would preclude setting options like so?

1. --festival-includes with a default value (if unset) to /usr/include/festival

2. --festival-libs with a default value (if unset) to /usr/lib/libfestival.XXX

The same goes for estools.

Answer 2

There is no need for the package maintainer to worry about these details at all; it is the responsibility of the user. If the user has installed a library in a non-standard location, then the user needs to add LDFLAGS=-L/path/to/lib to a CONFIG_SITE file or to every invocation of configure or put that path in the compiler's search path through some system dependent mechanism. Similarly, the user should append -I/path/to/include to CPPFLAGS.

In other words, debian is doing the right thing by simply installing the libraries and headers in the standard location. Anyone choosing to install the libraries in a non-standard location is giving themselves more work. It's not your responsibility to fix their mistakes.

Adding options like --with-festival or --with-festival-headers is not helpful; the user can just as easily assign to LDFLAGS and CPPFLAGS, and those variables are standardized.

Answer 3

Some platforms have adopted the Filesystem Heirarchy Standard - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard .

This should really be reflected in autoconf, instead of insisting that the user should deal with it by setting CFLAGS, because /opt/openssl/lib is no longer a "non-standard" location.

The FHS also specifies that /usr/local is a "Tertiary hierarchy for local data, specific to this host." So arguably, /opt should really be checked first.

More on FHS /opt -> http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES