RE: AC_PATH_PROG requires target be executable

[Botte, James - James M]

NOTICE:
All information in and attached to the e-mail(s) below may be proprietary, 
confidential, privileged and otherwise protected from improper or erroneous 
disclosure.  If you are not the sender's intended recipient, you are not 
authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message.  If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message (electronic, paper, or otherwise).  Thank you.

> A quick glimpse to the 2.59's lib/autoconf/programs.m4 shows that
> Autoconf always tried to check whether the file is executable.

Philosophically, I can understand why it was done, since in most cases,
the AC_*_PROG macro is going to be looking for an executable. In my
case, I'm building with user permissions and I am running with elevated
permissions, so the model breaks down (since the program is 550). The
searching of the PATH as done by the AC_*_PROG(S) macros also struck me
as tying the build environment to the execution environment, but it is
possible to either change the PATH environment variable before invoking
configure or, more elegantly, the AC_*_PROG(S) macros support the
specification of a search path to allow the target environment to be
"modeled" at build time.

I would argue that the AC_*_PROG(S) macros are actually performing two
unrelated functions as currently implemented: searching the executable
PATH looking for a program and then verifying it's permissions. I
propose that it would make the interface cleaner if the two operations
were broken apart into one operation to locate the program
(AC_*_PROG(S)), and some other operation to determine if a file has the
required permissions for the user, group, or users that will be
accessing it. This would also provide a generic mechanism for testing
file permissions as part of a configure script.

I would lastly argue that checking the permissions of executables, or
the settings for any file for that matter, is really something that can
only be done at runtime anyway. Having a permissions check at build time
for a package does provide something of a sanity check, but only for the
build box (which is often configured differently from target boxes).
This implies that checking for permissions of programs at build time is
at best a sanity check, and at worst, misleading and perhaps doesn't
even belong in things at the "autoconf" stage... unless it was a program
or file that is required by the configure script for the build
infrastructure.

> Should AC_PATH_FILE be added to Autoconf?

To summarize, I am of the opinion that the test for executability should
be removed from AC_*_PROG(S), and that a generic permissions testing
macro should be created to test files required by the configure script
(and as a basic sanity test on the build box for programs required by
the application runtime).

Until then, I will implement a workaround in my configure.ac file to set
the as_test_x variable to 'test -f' for the duration of the problematic
program test (so it will still find it using the PATH, but will not test
it for executability).

Once folks have decided the direction (if any) that makes sense for
autoconf, please let me know what I can do to help out.

> And, yes, have a nice day.  :-)

Thank you! And you too :).

I appreciate all your assistance,

    James