Mail Archives: djgpp-workers/2001/01/02/04:24:17
On Tue, 2 Jan 2001, Tim Van Holder wrote:
> > It looks like saying "IFS=';'...." here will DTRT for us. Autoconf
> > can do that automatically if "$COMSPEC$ComSpec" is non-empty, and the
> > same solution will work for MinGW.
> >
>
> > Isn't this easier to have Autoconf define ac_path_sep variable whose
> > value is either : or ;, depending on "$COMSPEC$ComSpec", and then use
> > ac_path_sep in the above snippet? Then you will not need a
> > DJGPP-specific test and won't need to convert drive letters to /dev/c
> > format.
> I already have an ac_pathsep variable (and although I currently depend
> on a site file to override the default ':', I suppose I could make the
> default depend on the comspec test).
If ac_pathsep already exists, and is set correctly for DJGPP in
config.site, you can simply use it.
> However, it's not a path that's being split here, it a template spec.
The Unix code uses `:' because a file name is unlikely to include that
character, due to `:' being a PATH separator. The same logic works for
DOS/Windows. So I don't see any reason not to use ac_pathsep here. This
is one of the causes it was introduced, after all.
> And using ';' here (or even worse,
> CONDITIONALLY using ';'), would require changing configure.in files all
> over the place.
That happens with each new release of Autoconf, anyway. ANd not because
of DJGPP-related issues.
The change should be done in a way that defers the expansion of
ac_pathsep until the time when the configure script actually runs, i.e.
it should not be expanded at the time the configure script is _created_
by Autoconf. Then the resultant script will DTRT on all platforms.
> Example:
> AC_CONFIG_HEADER(foo.h:foo.hin)
> AC_CONFIG_FILES([po/Makefile.in:po/Make-in foo.spec:foospec.in)
This is a different, even if related, issue. Are you saying that the
IFS=: etc. is used to parse these specs?
> If the configure script made from this is called with --srcdir=d:/src
> (or if, as with emacs, the configure script forces srcdir to be
> absolute)
configure scripts should be called with --srcdir=/dev/d/src form of file
names, otherwise lots of other places in the configure script will fall
apart.
I don't think I understand what does Emacs add to this problem. Can you
elaborate?
> > Why should we go to such great lengths to make Autoconf
> > different? All it takes to make the script be runnable on Unix is to
> > run dtou on it by hand--hardly a problem for someone who wants to use
> > a configure script.
> I suppose so. Still, since all it takes is that call to dtou, this does
> not seem to big of an issue.
If it's easy to add, why not, indeed? But this discussion seems to
indicate otherwise. I was wondering whether the price is worth paying.
> Note that there is another valid reason to use dtou, besides Unix
> compatibility of the output. In many case, makefiles and/or will use
> 'cmp' to compare file to decide whether some command needs to be run.
In most of the cases where `cmp' is used, you need utod, not dtou. I
find it hard or impossible to know in advance whether you should do one
or the other, or nothing at all, to get the results the maintainers had
in mind. There are also the cases where `cm' should simply be replaced
with `diff'.
> > It's not a Bash problem, it's a Linux kernel problem: it cannot grok
> > the magic "#!/bin/sh" signature if it ends in \r\n. Unlike in the
> > DJGPP port, on Unix the kernel interprets #!/bin/sh and invokes Bash.
> Maybe, but the problems I'm referring to come when running 'sh
> ./configure' and the like, so the kernel doesn't have to do any
> grokking.
I think you are wrong: what Bash does in this case is still make the
EXEC system call, and the kernel gets to decide how to run the script.
> > Does the problem happen because you run dtou with "exec 4>" still in
> > effect, or because something else? In other words, if you don't
> > invoke dtou, does the problem go away?
> Because of the exec 4>, bash keeps the file open. Zhen dtou needs to
> remove the original (so it can rename the dtou'd file to it), this
> fails, as DOS won't let you do that to an open file.
This is actually more complicated. On DOS, the remove succeeds (and
corrupts your filesystem, leaving behind occupied clusters with no
directory entry pointing to them). On Windows 9X, this fails (which is
probably what you saw). On NT, you get what you get on Unix: the file
removal succeeds, but the file remains on the disk until closed.
> > If the problem happens only because you run dtou, then maybe running
> > it in a different place (or not running it at all ;-) would solve the
> > problem. Or maybe the script could "exec 4>/dev/null" on all
> > platforms, without testing for DOS/DJGPP.
> I'm only running the exec 4>/dev/null to make dtou work (on Unices, you
> can remove/rename/etc an open file without problems), and since this is
> just about the final command run in the script, using the exec on each
> platform is probably unwarranted.
Did you try to make the dtou call part of the "trap ..." group? I think
you can catch normal exits with `trap', can't you?
- Raw text -