Date: Mon, 01 Jan 2001 18:47:43 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Tim Van Holder" Message-Id: <3405-Mon01Jan2001184742+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp-workers AT delorie DOT com In-reply-to: Subject: Re: Robust shell-based test for DJGPP? References: Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Tim Van Holder" > 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.