Date: Wed, 11 Apr 2001 21:50:17 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
Message-Id: <1225-Wed11Apr2001215016+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <CAEGKOHJKAAFPKOCLHDIKEGGCCAA.tim.van.holder@pandora.be>
Subject: Re: New bash 2.04 beta release
References:  <CAEGKOHJKAAFPKOCLHDIKEGGCCAA DOT tim DOT van DOT holder AT pandora DOT be>
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

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Wed, 11 Apr 2001 19:01:19 +0200
> 
> An AC_SUBST for a pathsep was very desirable, as it allows files (such
> as, in the case of autoconf, the test harness) to use the correct pathsep
> for the system.

This is not required by DJGPP.  Our Bash will do the right thing both
with ':' and with ';', provided that the configure script and
PATH_SEPARATOR are consistent.  That is, if the configure script uses
';' and PATH_SEPARATOR is ';', the script will work, and the same for
':'.

> It's also very useful for typical Makefile's that build manuals; they tend
> to set TEXINPUTS (using a ':' as separator).  Now such Makefile.in's can
> use @PATH_SEPARATOR@ instead and get the correct pathsep at configure time.

This is indeed a welcome change, one that I was talking with varuious
maintainers about for a long time.  But it doesn't need to use the
same variable name.  In fact, it better not use PATH_SEPARATOR,
because it is quite possible that some scripts which are run by Make
do not honor PATH_SEPARATOR and still rely on ':' without testing.
This is the breakage that I'm afraid of.

> Come to think of it, how likely is it for external, :-using scripts to
> be run during configure?

I don't know.  Lately, we see new scripts popping up both during
configure time and build time.  libtool and depcomp are two notable
examples.  I think it would be good to not have to change the
DJGPP-specific files and ports each time a new script is born.