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: Fri, 29 Dec 2000 18:45:30 +0100
Message-ID: <NEBBIOJNGMKPNOBKHCGHIECECAAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-4"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A4CB0B0.C36EA08F@softhome.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id MAA30069
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

> Well, I don't know in what cases you're going to use your DJGPP tests,
> but sometimes it might be a good idea to check for specific features instead,
> for example, you don't have to explicitly check for DJGPP if you test fork()
> or drive letters availability. But again, I didn't see your code.
The test is only used where needed to adjust the behaviour of autoconf and the
configure script it generates; it is NOT used to change the behaviour of the
package being configured.

I use it in the following situations:

* at the start of configure to default prefix to /dev/env/DJDIR. This allows configure
to pick up the config.site file from $DJDIR/share (and a config.site file is
REQUIRED to make configure behave correctly under DJGPP (it needs to override
some variables (pathsep, ln -s, test to find executables))).

* in AC_PATH_PROG to only return the filename, not the path. This allows a
configured tree to be distributed. This is the most disruptive change I made, as
it does not correspond to the normal behaviour of configure; I believe that for
DJGPP, this is what we want. I've yet to see many configure.in's that rely
on the path returned by AC_PATH_PROG, and those that do usually do so to
catch known broken versions (and as we all know, no DJGPP program is
broken ;-) ). Anyway, please refrain from bashing me over this until I have
sent my patches to the autoconf team for scrutiny.

* 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.
  A similar transformation is done on ac_given_srcdir to avoid getting caught
  in an endless loop because of the colon.

* 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
* in autoconf, so I can close the output file (exec 4>/dev/null) and run dtou on it

As for Martin's suggestion to use $DJGPP, that would probably be more robust
indeed, as users are free to rename djgpp.env provided $DJGPP points to the
right file.

So, this will likely be better:

if test -d /dev/env/DJDIR -a -n "$DJGPP" -a -f "$DJGPP"; then
  # Hooray! DJGPP!
fi

Since config.guess uses it, I suppose I could indeed also use 'uname', testing for
'pc' as machine and 'MS-DOS' as OS. But they seem slightly to generic (it is
feasible some other (future) environment would use the same return values, but
it's much less likely that som other environment uses both DJDIR, DJGPP and
the /dev/env/ system).

Any further suggestions are more than welcome.