Xref: utzoo comp.sys.sgi:2629 comp.unix.ultrix:2369 comp.sys.mips:376
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!arisia!sgi!shinobu!odin!ramoth.esd.sgi.com!msc
From: msc@ramoth.esd.sgi.com (Mark Callow)
Newsgroups: comp.sys.sgi,comp.unix.ultrix,comp.sys.mips
Subject: Re: Distinguishing "true" MIPS box from DECstation at compile time
Message-ID: <2103@odin.SGI.COM>
Date: 18 Dec 89 21:56:08 GMT
References: <89Dec15.145750est.2273@neat.cs.toronto.edu> <1300@uakari.primate.wisc.edu>
Sender: news@odin.SGI.COM
Reply-To: msc@sgi.com
Organization: Silicon Graphics Inc., Entry Systems Division
Lines: 30

In article <89Dec15.145750est.2273@neat.cs.toronto.edu>,
moraes@cs.toronto.edu (Mark Moraes) writes:
> 
> *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*

Yes, Yes,a thousand times yes.

Even though the system vendors don't define "feature ifdefs" you can write
your code as if you had them.  You simply have to create a header that does
all the ugly stuff (like that in the rest of the referenced article) and
sets the appropriate "featuredefs".

We tried to persuade the X consortium to change the ifdef's in X to a scheme
like this.  Their response was lukewarm.