Subject: Re: m4 port: return program name as 'm4' not '/some/path/m4.exe'
	[PATCH]
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: djgpp-workers AT delorie DOT com
Cc: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
In-Reply-To: <Pine.SUN.3.91.1030109075038.16256B-100000@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1030109075038 DOT 16256B-100000 AT is>
Content-Type: text/plain
Organization: 
Message-Id: <1042101053.4734.8.camel@leeloo>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 09 Jan 2003 09:30:53 +0100
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 2003-01-09 at 06:53, Eli Zaretskii wrote:
> On Wed, 8 Jan 2003, Richard Dawe wrote:

> > but Tim van
> > Holder (hi Tim) told me the other day that it'll find directories called "foo"
> > in the path as well.
> 
> Isn't that a bug?  Does that happen on Unix and GNU/Linux systems as 
> well.

I was talking about Linux/Unix systems, where directories have the
'executable' bit set if the user/group/world are allowed to cd into
it.  I don't know if this Unixism is simulated by our test -x, but I
would hope so (or scripts that check for it would break).
IIRC the problem as that on some system, a standard path directory
had a 'm4' subdirectory, causing configure to break if it used
'test -x'.  Because of that, autoconf was changed to use executable
extensions instead; this has (currently) zero overhead and breakage
on Unixy systems (as the set of extensions needs to come from
environment/config.site at the moment), while also easy to use for a
djgpp port (ie adding a variable to our config.site).

-- 
Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>