autoconf-2.57 and AC_PREFIX_PROGRAM(): bug or a (mis)feature?

[Nelson H. F. Beebe]

The AC_PREFIX_PROGRAM() macro in autoconf-2.57 is documented like this
in the info system manual:

>> ...
>>    It may be convenient for users to have `configure' guess the
>> installation prefix from the location of a related program that they
>> have already installed.  If you wish to do that, you can call
>> `AC_PREFIX_PROGRAM'.
>>
>>  - Macro: AC_PREFIX_PROGRAM (PROGRAM)
>>      If the user did not specify an installation prefix (using the
>>      `--prefix' option), guess a value for it by looking for PROGRAM in
>>      `PATH', the way the shell does.  If PROGRAM is found, set the
>>      prefix to the parent of the directory containing PROGRAM, else
>>      default the prefix as described above (`/usr/local' or
>>      `AC_PREFIX_DEFAULT').  For example, if PROGRAM is `gcc' and the
>>      `PATH' contains `/usr/local/gnu/bin/gcc', set the prefix to
>>      `/usr/local/gnu'.
>> ...

The AC_PREFIX_PROGRAM() macro is relatively uncommon: I found only 68
instances among more than 2000 configure.{ac,in} files on my systems.

Earlier this week, on freshly-installed bare-bones OpenBSD and NetBSD
systems, we found that the generated Makefile for a GNU package that
used that macro ended up with

        prefix = .

instead of the expected GNU default

        prefix = /usr/local

Examination of the configure script code for setting ac_prefix_program
shows that it ultimately comes down to an evaluation of "dirname
PROGRAM", which returns "." if PROGRAM is a pathless name.

The autoconf documentation doesn't make clear what AC_PREFIX_PROGRAM
does when PROGRAM is not found.

It seems to me that the correct behavior in this case is to fall back
to the configure default (whatever ..../share/config.site says, or
else configure's GNU default of /usr/local), rather than to choose
".".  That directory is the build directory, and in practice, that
would never be chosen as an installation directory.

Comments?

For experiments, I used this simple setup:

        % ls -l
        total 1232
        -rw-rw-r--   1 beebe    staff        116 Mar 18 09:20 Makefile.in
        -rw-rw-r--   1 beebe    staff          0 Mar 18 08:32 config.h.in
        -rwxrwxr-x   1 beebe    staff      73288 Mar 18 08:32 configure
        -rw-rw-r--   1 beebe    staff         87 Mar 18 08:32 configure.in
        -rw-rw-r--   1 beebe    staff          0 Mar 18 08:31 x.c

        % cat Makefile.in
        prefix = @prefix@

        clean:

        mostlyclean:

        distclean:
                -rm -f config.h config.cache config.log config.status Makefile

        % cat configure.in
        AC_INIT(x.c)
        AC_CONFIG_HEADER(config.h)
        AC_PREFIX_PROGRAM(screen)
        AC_OUTPUT(Makefile)

One further point: my own view is that AC_PREFIX_PROGRAM is desirable
only for those rare instances where a program is to be installed in a
rather nonstandard location, like /usr/lib, and that in general, GNU
utilities should not use it if they would ordinarily work fine in
/usr/local/bin.

When they do use it, if there is a copy of the program installed in,
say, /usr/bin, then prefix gets set to /usr, instead of /usr/local,
which I personally view as wrong: user-installed code should never go
into the vendor-provided /usr tree, and software distributions should
never encourage novice installers to become root to do "make install".

If your autoconf folks agree with that interpretation, perhaps the
documentation of AC_PREFIX_PROGRAM could be sharpened to clarify when
it should be used, and when it should not be used.


-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: address@hidden  -
- Department of Mathematics, 110 LCB        address@hidden  address@hidden -
- 155 S 1400 E RM 233                       address@hidden                    -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------