Mail Archives: djgpp-workers/2001/04/12/13:15:13
> > > > 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
> > > ':'.
> > Ah, but not all those files will be shell scripts. Perl, for example,
> > does not honor PATH_SEPARATOR as far as I know.
>
> Sorry, I'm not following: if Perl doesn't honor PATH_SEPARATOR, why
> would setting PATH_SEPARATOR in any way affect how Perl works?
I was talking about the situation where a Perl script is produced by
autoconf, and it uses @PATH_SEPARATOR@ to walk the path (say, by
calling split() on $ENV{PATH}).
As I understand it, bash turns PATH back to a ';' version when calling
other programs, so perl would get a ';'-delimited $PATH regardless of
$PATH_SEPARATOR. So if configure uses ':' as pathsep becauses it honors
$PATH_SEPARATOR, it will probably run just fine, but produce output
which doesn't.
> If you meant to say that Perl scripts which were written to honor
> PATH_SEPARATOR will DTRT, then the name of the variable is not
> important; it can be anything.
For the situation above, it doesn't matter what the substituted
value is called; you'd still end up with a bad pathsep in the Perl
script.
>
> PATH_SEPARATOR was introduced into the DJGPP port of Bash several
> versions (and quite some time) ago. We were there first; it is not
> nice for Autoconf to usurp that name when doing so could cause trouble
> for DJGPP.
True enough, but I still don't see a big problem. PATH_SEPARATOR is only
overridden inside configure; this is what we want, because we want ';'
to be used there, and there are few external scripts that would be run
suring configure anyway. If necessary, I could limit the potential
breakage by only setting PATH_SEPARATOR when actually walking the path,
and right before the creation of config.status (so it can be substituted).
As for @PATH_SEPARATOR@, this only affects files that actually use it.
This is currently limited to autoconf's test suite, and my locally patched
version of cvs automake. If you feel it's absolutely essential, I'd be
willing to change the name of this variable to @PATHSEP@ (it would be
less verbose anyway).
Again, I'd like to note I've already configured several packages using
this autoconf and have not yet run into any trouble from PATH_SEPARATOR.
> > Also, not all these scripts will be using a path variable that is
> > recognized and handled by bash.
>
> PATH_SEPARATOR was introduced to handle PATH and it alone. It doesn't
> solve all the problems with using ':' in Unix shell scripts, but it
> did succeed to let us run configure scripts, and also some other
> scripts, such as mkinstalldirs, unaltered. If there's a need and a
The point here is that scripts that use both handled and unhandled
colon-separated variables are still broken with PATH_SEPARATOR. If they
were part of an autoconfiscated package, they would run fine if they used
@PATH_SEPARATOR@.
> will to solve more problems specific to Autoconf, I will be the first
> to applaud, but it doesn't feel right to affect PATH_SEPARATOR while
> at that. PATH_SEPARATOR is a tested feature, so I think it should be
> left alone.
I'm not suggesting changing how PATH_SEPARATOR works, but I am suggesting
it is a workaround for broken scripts, rather than a real feature.
Getting scripts to DTRT without special workarounds should be the
ultimate goal, IMHO.
> Don't forget that there are quite a few unmaintained packages out
> there, or packages for which newer DJGPP ports are not available.
> Those packages will still need to rely on the old ways of getting them
> to configure and build in the years to come. We cannot rely on always
> having the bleeding-edge Autoconf in every package DJGPP users
> compile.
True, but a single pass of updating to 2.50 should ensure they no longer
require PATH_SEPARATOR to be set. I'd be more than happy to do this,
though it'd probably take a few weeks.
> Also, there are important packages that still don't use Autoconf. One
> notable example is GDB, where the gdb/ subdirectory is not
> autoconfiscated yet.
Hmm... from gdb/configure.in:
dnl Autoconf configure script for GDB, the GNU debugger.
dnl Copyright 1995, 1996, 1997, 1998, 1999, 2000, 2001
dnl Free Software Foundation, Inc.
dnl
dnl This file is part of GDB.
dnl
There's a few directories in the gcc tree that aren't autoconfiscated,
that's true (the C++ library for 2.95.x, for one).
> > If it were just scripts being created and run, there would indeed be
> > no problem; just setting PATH_SEPARATOR to ':' in config.site would be
> > enough.
>
> Whether to set PATH_SEPARATOR in config.site or not is a separate
> question. If newer versions of Autoconf don't require that because
> the configure scripts they produce do the Right Thing without
> PATH_SEPARATOR, we can remove that setting. Or maybe we will decide
> not to remove it, because some packages which use old Autoconf
> versions, or don't use Autoconf at all, still need it.
>
> But IMHO Autoconf should not _require_ a user to do anything specific
> with PATH_SEPARATOR, because that would be a step backwards.
It doesn't require any setting, it simply overrides it for the duration
of configure with the pathsep it found. As such, it's prefectly fine
to keep the setting in config.site, as it would help 2.13-based configures.
> In other words, if the new Autoconf produces scripts which
> automatically detect the path separator character and then use it,
> then those scripts should not require that PATH_SEPARATOR be set in
> any special way, and they should not themselves set PATH_SEPARATOR to
> anything. They should use the normal ac_* variables internal to
> Autoconf.
But if configure uses only $ac_path_separator, which would have been found
as ';', it would not be able to walk the path if PATH_SEPARATOR is set to
':'.
> Setting PATH_SEPARATOR in a Makefile is likewise evil,
> IMHO, because it interferes with the user environment without any real
> reason.
Also, you seem to have misunderstood the use of PATH_SEPARATOR wrt
Makefiles; $PATH_SEPARATOR would not get set there. You'd have
SET_TEXINPUTS = \
TEXINPUTS="${TEXIDIR}@PATH_SEPARATOR@.@PATH_SEPARATOR@$(srcdir)@PATH_SEPARAT
OR@$(READLINE_DIR)@PATH_SEPARATOR@$(GDBMI_DIR)@PATH_SEPARATOR@$$TEXINPUTS"
in Makefile.in, which would end up in Makefile as
SET_TEXINPUTS = \
TEXINPUTS="${TEXIDIR};.;$(srcdir);$(READLINE_DIR);$(GDBMI_DIR);$$TEXINPUTS"
There could only be a problem if someone has
PATH_SEPARATOR = @PATH_SEPARATOR@
and is running 'make -e' or whatever so it gets exported to the environment.
If this is a realistic danger, it would be easy enough to note this issue in
the automake manual.
> > > 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.
> > True, but then it's the scripts that are broken and need to be fixed.
>
> That might be true, but how does this help Joe Random User who just
> wants to build the darn thing? It's the users I'm worried about, not
> about fixing every script out there. Most of these users don't have a
> clue about shell script programming, and will not be able to fix such
> problems.
Joe Random User would be using a DJGPP package, which would by definition
have been ported.
And again, this would only affect scripts that
a) are run during configure. These are few and far between.
b) are run from a make command, which sets PATH or some other var using
';' when it shouldn't. Since no current makefiles use the pathsep
system, this is a non-issue. If and when it does occur, it's trivial
to fix when building a DJGPP package.
> > In any case, it would be easy enough to modify Makefile.in where
> > necessary and replace the @PATH_SEPARATOR@ with ':' for those instances
> > where ';' won't work. I strongly believe using ';' as default on DOS
> > is a Good Thing.
>
> ';' is indeed a Good Thing; using PATH_SEPARATOR as a vehicle for that
> is _not_.
As stated below, overriding PATH_SEPARATOR during configure seems to be the
only way to it to run properly _and_ produce correct output.
> > So what would you have me do?
>
> I think the name of the variable used by Autoconf should be changed to
> something of the ac_* variety.
As said above, it already is; but if the value found by autoconf (always
';' on DOS) doesn't match $PATH_SEPARATOR, configure won't be able to walk
the path, and won't find any programs. If we let $PATH_SEPARATOR
override the ac_ variable, we may end up with badly configured output.
So overriding $PATH_SEPARATOR during configure seems to be an acceptable
compromise; one that could even be minimised by only overriding
$PATH_SEPARATOR when actually dealing with $PATH.
- Raw text -