From:	"Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To:	<djgpp-workers AT delorie DOT com>
Subject:	RE: Ribust shell-based test for DJGPP?
Date:	Sun, 31 Dec 2000 15:32:29 +0100
Message-ID:	<NEBBIOJNGMKPNOBKHCGHKECMCAAA.tim.van.holder@pandora.be>
MIME-Version:	1.0
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
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

> 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.

- Raw text -