[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: --help should not require --srcdir

From: Eric Blake
Subject: Re: --help should not require --srcdir
Date: Thu, 28 Jul 2011 12:21:51 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.11

On 07/28/2011 12:13 PM, Sam Steingold wrote:
* Eric Blake<address@hidden>  [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

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   address@hidden    +1-801-349-2682
Libvirt virtualization library

reply via email to

[Prev in Thread] Current Thread [Next in Thread]