Mail Archives: djgpp-workers/2001/04/12/05:19:48
On Wed, 11 Apr 2001, Tim Van Holder wrote:
> > > 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?
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.
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.
> 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
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.
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.
Also, there are important packages that still don't use Autoconf. One
notable example is GDB, where the gdb/ subdirectory is not
autoconfiscated yet.
> 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.
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. Setting PATH_SEPARATOR in a Makefile is likewise evil,
IMHO, because it interferes with the user environment without any real
reason.
> > > 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.
> 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.
> 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_.
> 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.
- Raw text -