[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf 2.53 doesn't find autom4te
From: |
Akim Demaille |
Subject: |
Re: autoconf 2.53 doesn't find autom4te |
Date: |
13 Jun 2002 14:31:52 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) |
>>>>> "Bruno" == Bruno Haible <address@hidden> writes:
Bruno> Akim Demaille writes:
>> It is a bug from the user if autoconf cannot be found in the PATH.
Bruno> Akim,
Hi Bruno!
Bruno> what do you think we have support for --prefix in autoconf for?
Bruno> If what you say were right, namely that the user never must
Bruno> call programs outside of PATH, then every user could install
Bruno> his stuff in /usr/local/bin or $HOME/bin, and there would never
Bruno> be the need for --prefix.
--prefix is there for the executables to find their files, because
there is no such thing as PATH for these files.
Bruno> The world is not that simple.
Agreed.
>> It is wrong to hard code locations in the binaries.
Bruno> All GNU packages which install multiple files need this. gcc
Bruno> needs this to find its lib/gcc-lib/... dir, all
Bruno> internationalized packages need to hardcode LOCALEDIR so they
Bruno> find the message catalogs, vim needs to hardcode its help
Bruno> texts, and so on.
But then again, in the present case there is something standard named
PATH. For instance, I wouldn't be hurt if NLS had something like
/etc/ld.so.conf plus some envvar to override at runtime.
>> Bypassing PATH is far worse, as you are breaking the most basic
>> Unix convention: obeying PATH.
Bruno> This is not one of the most basic Unix conventions. Otherwise
Bruno> there wouldn't be system calls like execl() and execv().
:)
I'm referring to users, who are certainly more used to PATH than
calling execl, compiling, and running that program to run autoconf.