From: "Tim Van Holder" To: Subject: RE: Ribust shell-based test for DJGPP? Date: Sun, 31 Dec 2000 15:32:29 +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: <3791-Sun31Dec2000122028+0200-eliz@is.elta.co.il> 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 JAA12373 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 > Why do you need to run dtou? It shouldn't be required with Bash 2.03 > and later (and you are going to require the latesrt Bash to support > /dev/env anyway). Two reasons: a) I don't think anything stops people from using an earlier bash, compiled with 2.03. They'd have /dev support, but not mixed EOL handling. b) I'd like the output to be compatible. A configure script created on a DJGPP system should work cleanly on a Linux system (and the CR's can cause real trouble). This does not apply to running dtou on config.status of course, as that should only be run on the system it was created on. > > if test -d /dev/env/DJDIR -a -n "$DJGPP" -a -f "$DJGPP"; then > > # Hooray! DJGPP! > > fi > Is the DJGPP variable set in the case when you are cross-compiling? It shouldn't matter - the changes should not affect the configuration process itself they only work around problems encountered when run under DOS. If using DJGPP as a cross-compilation platform, you'll still need to do so (and $DJGPP would definitely be set); and if cross-compiling to DJGPP, you'd be running a non-DJGPP system so the workarounds should not be enabled (and since you wouldn't have /dev/env then, they won't be). The test as listed above only fails in three situations: a) DJDIR isn't set in djgpp.env (or anywhere else). Why someone would want to remove it from djgpp.env is beyond me. b) DJGPP isn't set. Any standard DJGPP installation will have this, so this should be rare as well. c) A non-DJGPP system happens to have a /dev/env/DJDIR/ directory AND a $DJGPP envvar that contains a file reference. This should be pretty rare as well. So it's not watertight, but I think it's the closest we can come without requiring external tools. Currently, I use this test at each point I added DJGPP-specific code. I suppose I could change this and only use it at the very top of configure and set some internal variable ($ac_djgpp maybe) to yes/no. This would allow systems where the test fails to override this in a site file.