Mail Archives: djgpp-workers/2001/04/11/13:02:08
> If Autoconf sets PATH_SEPARATOR to ';' to force Bash to DTRT, that is
> okay. But if Autoconf sets it to ';' for its own needs, then it might
It does both, really. It sets an internal var (ac_path_separator) to
be used inside configure(.in), and sets PATH_SEPARATOR, partly as a side
effect of AC_SUBST, and partly intentionally to avoid problems if bash
uses a different value (so walking the path won't break).
> break Bash or scripts run by Bash, and this is precisely the conflict
> we should avoid. That is why I suggested that Autoconf should use a
> variable by another name.
I think I originally suggested PATHSEP as variable name for AC_SUBST,
but the autoconf maintainers preferred PATH_SEPARATOR, I believe. At
the time, I did not see a problem with that (and I'm still not entirely
sure it is a real problem now).
> > Also, there's an AC_SUBST for PATH_SEPARATOR, so it would get
> > set anyway.
>
> I don't think I understand what this means. Who and why sets
> PATH_SEPARATOR via AC_SUBST, and why it cannot be avoided?
AC_SUBST(foo, $bar)
in an autoconf file has 2 effects:
1) it sets a variable foo to $bar, and
2) it adds '@foo@' to the list of variables to substitute in
templates like Makefile.in.
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.
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.
So at configure startup, the pathsep gets deduced, and PATH_SEPARATOR gets
AC_SUBST'ed.
> > There's no clean way out of this, I guess
>
> I think having two different variables, one for Bash, the other for
> Autoconf, is a clean way. If not, please tell why not.
I could try to get the AC_SUBSTed variable changed (seems more likely than
changing the variable used by bash), but the conflict with autoconf using
the "correct" pathsep (;) for walking the path and bash using ':' (so
PATH is ':'-separated) will remain, won't it?
I could probably amend autoconf to only set PATH_SEPARATOR at the very end
of configure (just before config.status gets created); it won't resolve
the potential problem if bash uses ':', but at least it won't break any
scripts that may be run while configure runs.
Come to think of it, how likely is it for external, :-using scripts to
be run during configure? Usually, configure runs pretty much stand-alone
(excepting libtool, which seems to do just fine with PATH_SEPARATOR set to
';'). M4 fragments used to build aclocal.m4 may be using a hardcoded colon,
but those can be easily adjusted to use $ac_path_separator like they should.
> > So let me know which packages have scripts that break with
> > PATH_SEPARATOR=';'; I'll endeavour to adapt those packages to use
> > autoconf 2.50 and use @PATH_SEPARATOR@ to configure themselves to work
> > correctly on DOS.
>
> I think this isn't practical. Even if we come up with a list of such
> scripts, a new one added tomorrow, or a new ported package will undo
> your efforts.
My point is that new DJGPP packages will probably be using autoconf 2.50
once it is available and proven (I've been using it for quite some time
now without problems (it configures binutils & gdb nicely)), and in such
a setup, correcting scripts in the package is fairly trivial. So only
existing packages may need adjusting to work properly out-of-the-box
without requiring PATH_SEPARATOR=:. And since I'm not sure there are
many such packages, I figured it would not be too large a task.
> Does Autoconf need to export PATH_SEPARATOR to subordinate Bash that
> it runs? If not, maybe Autoconf needs to use ';' for itself, but
> leave the normal setting alone.
If it were just being set for bash, I suppose I could have adjusted the
path walking code to do:
ac_save_PATH_SEPARATOR=$PATH_SEPARATOR
PATH_SEPARATOR=$ac_path_separator
<walk path>
PATH_SEPARATOR=$ac_save_PATH_SEPARATOR
(though I'm not sure such a change would have been accepted). As it
stands, it is mainly set for AC_SUBST's sake.
- Raw text -