On 07/28/2011 12:13 PM, Sam Steingold wrote:
* Eric Blake<roynxr@xxxxxxxxxx> [2011-07-28 11:35:30 -0600]:
However, there is no reason for any program to report an error when
given the --help switch, no matter where the program is located.
Yes there is, if the program can do nothing useful in its current
location.
try "ls --help" in an unreadable directory.
it will print help, not report an error saying that the current
directory is not readable.
ls is location-independent. It is designed to run no matter where
either ls is located or where the current working directory is.
configure is location-dependent. It is only designed to do something
useful when located in alongside the sources that it was generated from.
However, while it matters in which directory configure lives, it does
_not_ matter where the current working directory is - you can run
/path/to/configure, ../configure, or any other construct where a
correctly-located configure living in an appropriate srcdir, distinct
from your choice of current working directory.
I don't buy your argument as justification for always making ./configure
--help succeed, when ./configure was moved out of place. And I already
told you that I welcome patches that make configure give nicer error
messages stating that the script is useless when not located correctly.
Additionally, there's a difference between code that can be run from
anywhere (configure and ls both fit this) and relocatable code (ls is
typically relocatable, configure is not). GNU Coding Standards do not
require relocatable code, and when you look at packages like gettext
that provide relocatable binaries, you can see why that is such a
difficult bonus feature to add. And even then, while gettext is
relocatable, it is only relocatable if you move ALL of the helper files
that the primary binary uses to reside in a parallel directory structure
similar to where the binary was originally installed. If you relocate
the main binary but not the helper scripts and shared libraries, then
the binary in the new location will not function correctly. You can
think of configure scripts in the same manner - they can be invoked from
anywhere, but if relocated, you must also relocate everything else that
the script needs for full functionality.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
