Date: Mon, 1 Jan 2001 08:45:57 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: djgpp-workers AT delorie DOT com Subject: RE: Ribust shell-based test for DJGPP? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 29 Dec 2000, Tim Van Holder wrote: > The test is only used where needed to adjust the behaviour of autoconf and the > configure script it generates Is the generated configure script supposed to run in the native DJGPP environment, that is, on DOS or Windows system with DJGPP development kit installed? I understand this is so, otherwise what you do is wrong: the default prefix should not be /dev/env/DJDIR, AC_PATH_PROG should not return the basename, etc. > * at the start of configure to default prefix to /dev/env/DJDIR. 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. > * 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. > * in config.status, I use this to detect DJGPP, and if found, I turn a leading > drivespec x:/ in an output file into /dev/x/, so the colon will not cause trouble > when config.status separates output file and template. A more elegant way > of handling this could be found, but this is an easy workaround. 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. > * at the end of configure, so I can run dtou on config.status > * in autoupdate, so I can run dtou on the updated configure.in > * in autoheader, so I can run dtou on the output file Since you are obviously talking about producing files for a native DJGPP build (see above), I don't see the reason for running dtou in the first place. > * 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. In sum, I think the only special thing you need to do is to force the configure script find the config.site file. All the rest is either optional or can be solved by other, less intrusive means. To find config.site, all you need is to say something like "test -f /dev/env/DJDIR/share/config.site". I believe this is both more robust and pinpoints exactly what you want to find out.