autoconf-patches
[Top][All Lists]
Advanced

[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.



reply via email to

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