From: "Tim Van Holder" To: Subject: Re: Robust shell-based test for DJGPP? Date: Mon, 1 Jan 2001 12:59:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id GAA29499 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 > 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. That's my point: the configure script generated should run on both DOS/Windows and Unices. That's why the changes (/dev/env, AC_PATH_PROG) are activated by the tst; if DJGPP isn't found, all these things behave in the original way. Examples: # part of _AC_INIT_DEFAULTS if test -d /dev/env/DJDIR -a -n "$DJGPP" -a -f "$DJGPP"; then ac_default_prefix=/dev/env/DJDIR else ac_default_prefix=/usr/local fi # from AC_PATH_PROG case $$1 in [[\\/]]* | ?:[[\\/]]*) ac_cv_path_$1="$$1" # Let the user override the test with a path. ;; *) AC_SHELL_PATH_WALK([$4], [if test $ac_test_f "$ac_dir/$ac_word"; then if test -d /dev/env/DJDIR -a -n "$DJGPP" -a -f "$DJGPP"; then # In order for DJGPP-based packages to be distributable, we can't use # a specific path here. This is not a perfect solution, but better # than requiring a uniform file system structure on each PC. ac_cv_path_$1="$ac_word" else ac_cv_path_$1="$ac_dir/$ac_word" fi break fi]) > 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). > > * 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; 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. > > * 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. 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=:) test -f "$f" || AC_MSG_ERROR([cannot find input file: $f]) echo $f;; *) # Relative if test -f "$f"; then # Build tree echo $f elif test -f "$ac_given_srcdir/$f"; then # Source tree echo $ac_given_srcdir/$f else # /dev/null tree AC_MSG_ERROR([cannot find input file: $f]) fi;; esac done` test -n "$ac_file_inputs" || AS_EXIT([1]) Because of the IFS=:, dos paths would be split up, causing autoconf no to find the templates. So because of this, I transform DOS-style paths to /dev ones internally (and since those transformed names are rarely displayed, this should not be too big a problem for the user. > > * 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. Since I'm talking about producig files that run on both DJGPP and Unices, the dtou's are needed. For one, a CRLF configure script will fail miserably (with very odd error messages) if fed to the Linux version of bash2. With the dtou's, I had no problem running a DJGPP-generated configure on Linux. Mind you, I didn't do exhaustive testing yet; that'll have to wait until I have my new box and am running Linux at home too. > > * 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. > 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. 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.