Mail Archives: djgpp-workers/2001/01/02/13:07:21
> > 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?
Exactly! And that's why I don't want ot use ac_pathsep for this.
If this was a purely internal thing, where configure built a
colon-separated list, it would be trivial to use a different separator
for DJGPP, but changing this would break automake and every single
configure.in script that used a non-standard template (as done often
for DJGPP ports (config.h:config.hin)).
> > 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.
Just the snippet discussed above, actually.
> I don't think I understand what does Emacs add to this problem. Can you
> elaborate?
Emacs's configure forces srcdir to be absolute:
== snippet from emacs 20.7's configure.in
#### Make srcdir absolute, if it isn't already. It's important to
#### avoid running the path through pwd unnecessary, since pwd can
#### give you automounter prefixes, which can go away. We do all this
#### so Emacs can find its files when run uninstalled.
case "${srcdir}" in
[[\\/]]* | [[a-zA-Z]]:[[\\/]]* ) ;;
. )
## We may be able to use the $PWD environment variable to make this
## absolute. But sometimes PWD is inaccurate.
## Make sure CDPATH doesn't affect cd (in case PWD is relative).
unset CDPATH
if test "${PWD}" != "" && test "`(cd ${PWD} ; sh -c pwd)`" = "`pwd`" ;
then
srcdir="$PWD"
else
srcdir="`(cd ${srcdir}; pwd)`"
fi
;;
* ) srcdir="`(cd ${srcdir}; pwd)`" ;;
esac
== end of snippet
> > 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.
You may be right - but if the kernel doesn't grok the #!/bin/sh, it should
barf pretty quickly, and as far as I recall, most of the script got
executed without errors (which is not to say nothing went wrong).
I'll try to do a few tests this week. But even if it is a kernel issue, the
dtou would have prevented it :-)
> 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?
I suppose I could, but I'm not sure whether the file will have been closed
at that point. I'll give it a try.
- Raw text -