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

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>

- Raw text -