Mail Archives: djgpp-workers/2001/01/01/11:49:21
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Mon, 1 Jan 2001 12:59:10 +0100
>
> > Why do you need this default? What is wrong with asking the user to say
> > "./configure --prefix=/dev/env/DJDIR"? And config.site already does that
> > for the user anyway.
> Laziness, I suppose. That way, I don't need to specify --prefix (like
> /usr/local on Unices, $DJDIR is a pretty good guess for DJGPP) and I can
> easily find config.site (without additional tests).
Sorry, I'm not sure I understand what you are saying. Do you agree
that setting the prefix to $DJDIR in config.sirte is good enough, or
do you still think you need a special change in Autoconf?
> > > * in AC_PATH_PROG to only return the filename, not the path. This allows a
> > > configured tree to be distributed.
> > Perhaps it is better to add something to config.site instead. This might
> > also require to add some ac_* variable to the configure script, but such
> > a change would probably be much less intrusive and complicated than
> > changing AC_PATH_PROG, and also much easier for the Autoconf maintainers
> > to accept.
> As the change ONLY affects configures run on DJGPP, I don't see a big problem
I think that, in general, it is better to solve problems in our
config.site than in Autoconf itself. config.site is under our
control, while Autoconf maintainers constantly change the code in a
way that repeatedly breaks DJGPP support (see the next item for an
example).
> If you insist, I'll add a variable to force the standard behaviour, but I
> don't think I'd want it to be the default. The fewer full DOS paths are used,
> the better.
I didn't want the standard behavior to be preserved, I wanted a change
to get the behavior you suggested, but without excess dependency on
Autoconf maintainers. If that is possible, of course.
> > I believe this should already be handled in a different way (swapping the
> > two -e options to Sed) in current development sources of Autoconf. I was
> > asking the developers to take care of that for a long time, and I think I
> > succeeded lately. Please check with them.
> In 2.13, it used to be that easy. But now they do:
>
> ac_file_inputs=`IFS=:
> for f in $ac_file_in; do
> case $f in
> -) echo $tmp/stdin ;;
> [[\\/$]]*)
> # Absolute (can't be DOS-style, as IFS=:)
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.
> Since I'm talking about producig files that run on both DJGPP and
> Unices, the dtou's are needed.
Producing configure scripts and other files that will run on Unix is a
noble goal, but I'm not sure how heavy a price should we pay for
that. AFAIK, this is the only case where such a goal is even set.
Info files produced by makeinfo, config.h and Makefile's produced by
configure, scripts produced by libtool---all these have the DOS EOL
format. 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.
> For one, a CRLF configure script
> will fail miserably (with very odd error messages) if fed to the
> Linux version of bash2.
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.
(But this is just a comment, it doesn't have much to do with the issue
we are discussing.)
> > > * in autoconf, so I can close the output file (exec 4>/dev/null)
> > Why do you need to close the output file in the DJGPP case? Isn't
> > that a bug? If so, it should be treated like a bug.
> Nope, it's DOS. The file was created through exec 4>file.name, and bash
> keeps the file open. Without the exec 4>/dev/null to close the file,
> dtou (stock 2.03, mind you) will not complain, but the output file will
> have DOS-style line endings.
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?
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 suppose I could do this instead (and I could use the site file to
> set the prefix as well). And since a site file is required for proper
> djgpp functionality anyway, it's indeed sufficiently robust.
> It doesn't obviate the need for most of the tests though, and since the
> changes are only run when they're needed (ie on DJGPP), they're hardly
> intrusive.
I think you should really minimize the number and volume of changes
you send to Autoconf maintainers. Each change brings questions,
suggestions for alternative solutions, discussions, rework, more
suggestions and discussions, etc. (And I didn't even say
``rejections'' yet ;-). Each such change can be later broken by some
changes in Autoconf. That's why I suggest to do as much as possible
in config.site, which is under our control and whose change process is
much simpler.
- Raw text -