3

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?

Jeremy Salwen
  • 8,061
  • 5
  • 50
  • 73

3 Answers3

3

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.

William Pursell
  • 204,365
  • 48
  • 270
  • 300
  • +1 for not reimplementing the wheel with the wrong tools. An option like ``--with-festival`` is legitimate when ``--without-festival`` means something. In other words, ``--with``/``--without`` options are meant to enable *or disable* the use of some other package. The actual configuration of search paths occurs with ``LDFLAGS`` and ``CPPFLAGS``. – adl Sep 07 '11 at 06:37
2

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.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • This requires twice as many command line options as I would like. Also, I'd really like to detect any file in SYSTEM_INCLUDE_DIRECTORY/festival/festival.h and be smart enough to just add SYSTEM_INCLUDE_DIRECTORY/festival to the search path. – Jeremy Salwen Jun 17 '11 at 02:15
  • Okay,thanks. I was confused about autotools. This is the right answer. – Jeremy Salwen Jun 18 '11 at 09:17
1

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

Michael V. Pelletier
  • 81
  • 2