Xref: utzoo comp.sys.sgi:2599 comp.unix.ultrix:2348 comp.sys.mips:361
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!neat.cs.toronto.edu!moraes
From: moraes@cs.toronto.edu (Mark Moraes)
Newsgroups: comp.sys.sgi,comp.unix.ultrix,comp.sys.mips
Subject: Re: Distinguishing "true" MIPS box from DECstation at compile time
Message-ID: <89Dec15.145750est.2273@neat.cs.toronto.edu>
Date: 15 Dec 89 19:59:00 GMT
References: <1300@uakari.primate.wisc.edu>
Organization: Department of Computer Science, University of Toronto
Lines: 89

bin@primate.wisc.edu (Brain in Neutral) writes:
># if mips
># if ultrix
>	DECstation
># else
>	true MIPS
># endif
># endif

Not so fast. SGI also defines "mips" on the Iris4D machines -- why
not, it's the CPU they use.

One possible solution, seen to work on our Iris4D (Irix3.2), our
DS3100s (Ultrix3.1), and our M/120 (Riscos4.0:

#ifdef mips
# ifdef ultrix
#  define ULTRIX_MIPS
#  define arch "ultrix-mips"
# endif
# ifdef sgi
#  define IRIS4D
#  define arch "iris4d"
# endif
# ifndef arch
   /*
    * Must be MIPSCo MIPS. Anyone know a way to differentiate between
    * RISCOS4.0 and UMIPS via cpp?
    */
#  define MIPS
#  define arch "mips"
# endif
#endif

Then one can use the symbols MIPS, IRIS4D, or ULTRIX_MIPS.

Note: this will presumably change once vendors start shipping truly
ANSI compatible compilers -- ANSI prohibits this sort of random
pollution of the namespace. (It'll be __mips__ or suchlike, and life
will become even more complicated, as people try to keep code
backwards compatible with things like"#if defined(mips) ||
defined(__mips__)"))

Another solution is to stick a wrapper script around cc, and get it to
define the symbols you want. The shell script I use for our SGI
machines is enclosed below.

*Soapbox on*

It is probably much better to ifdef on specific features that one
needs (eg.  BSD_SIGNALS, JOB_CONTROL, DIRENT, SHMEM, etc) than on a
specific vendor type, considering the way the zillion and one
"standard" deviants, er, variants, of Un*x are growing warts, er,
features. Relying on even the vendors operating system remaining the
same is probably not portable. As for the simple distinction between
BSD and SYSV, that's gone a long time ago, thanks to extensive
cross-breeding...

Then one can create configuration headers per machine -- s-machine.h,
sysdep.h, whatever, defining specific features on a per release basis,
as is sometimes necessary :-( The joys of maintaining a single source
tree for multiple architectures and OS deviants!

*Soapbox off*

#! /bin/sh -
# Fake CC driver that includes local and bsd stuff and links compatibility
# bsd routines. Also defines __iris4d__ and __irix__, as well
# as linking in /local/lib libraries before system defaults.
# Also munges output error messages from cc to BSD format, so it can
# be automatically parsed by Jove.
# Mark Moraes, University of Toronto
realcc=/usr/bin/cc
includes=
args=
for i
do
	case "$i" in
	-I*) includes="$includes $i";;
	-v) set -x;;
	esac
done
includes="$includes -I/local/include -I/usr/include/bsd"
tmp=/tmp/cc.bsd.$$
trap 'rm -f $tmp; exit $status' 0
$realcc -D__iris4d__ -D__irix__ $includes -L/local/lib "$@" -lbsd 2> $tmp
status=$?
# Postprocess errors - cc can produce stuff on stdout, for cc -M, f'rinstance
sed 's/^[^:]*: \([^:]*: \)\([^,]*\), \([^:]*: \)\(.*\)/"\2", \3\1\4/' $tmp >&2