Mail Archives: djgpp-workers/2001/04/11/16:26:33
> > 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. Also, not all these
scripts will be using a path variable that is recognized and handled
by bash.
So having a system in place that works on ALL files is a Good Thing.
If the autoconf manual states scripts should use @PATH_SEPARATOR@ to get
a proper pathsep, there's a good chance they may decide to adjust their
files, decreasing the work needed for a DJGPP port. If it says, do
this, but not for shell scripts, people may be confused as to why it is
needed at all and decide not to bother.
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.
> > 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.
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.
bash's use of PATH_SEPARATOR is a good stop-gap measure, but the end
goal should be to have the scripts fixed; and with these changes to
autoconf, it would be as simple as sending a small patch to the
maintainer of a script to have it start DTRT, as adding DOS support
no longer removes Unix support :-)
> > 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.
Yes, but depcomp is part of automake and therefore strongly tied to
autoconf. As long as we have a guy (currently me) on the autoconf and
automake teams (and possibly libtool as well, but that seems to handle
a DOSsy environment pretty well as it is), there's no real problem there.
What I meant was scripts that are not part of the build tools.
From what I've seen this happens very rarely, and I believe it is
acceptable to have to change those scripts if and when they do crop
up.
The only such scripts I can think of are the *-config scripts that are
becoming ubiquitous (especially in gnome), and those only report
configuration info (which by definition would use the proper pathseps
and stuff), so they're harmless.
So what would you have me do?
I could try to get the name of the SUBSTed variable changed, but I feel
it's not really needed, because the chances of pathsep conflicts inside
configure are pretty minimal IMHO.
I could also amend the pathsep checking to use PATH_SEPARATOR from the
environment if it is set; but then users would need to be made perfectly
clear that using ':' this will break things if nonstandard path variables
or non-shell scripts using path variables are used anytime during the
configure and build process.
- Raw text -