Xref: utzoo comp.sys.sgi:2637 comp.unix.ultrix:2375 comp.sys.mips:377
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!munnari.oz.au!basser!cluster!yar
From: yar@cs.su.oz (Ray Loyzaga)
Newsgroups: comp.sys.sgi,comp.unix.ultrix,comp.sys.mips
Subject: Re: Distinguishing "true" MIPS box from DECstation at compile time
Message-ID: <675@cluster.cs.su.oz>
Date: 20 Dec 89 21:36:10 GMT
References: <89Dec15.145750est.2273@neat.cs.toronto.edu> <1300@uakari.primate.wisc.edu> <2103@odin.SGI.COM>
Sender: news@cluster.cs.su.oz
Reply-To: yar@cluster.cs.su.oz (Ray Loyzaga)
Organization: Basser Dept of Computer Science, University of Sydney, Australia
Lines: 47

In article <2103@odin.SGI.COM> msc@sgi.com writes:
> In article <89Dec15.145750est.2273@neat.cs.toronto.edu>,
> moraes@cs.toronto.edu (Mark Moraes) writes:
> > 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
> > [Deleted]
> > 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.

The only problem with this approach is that all the sources that you develop
will have #includes of files that are not available on any other system,
you could #ifdef the includes but on the basis of what? The bottom line
is that you need to have an "include" file that defines the way the system
is set up, and this file is sourced by cpp with every invocation.
This file should contain the "standard defines" such as mips or sysV etc,
these are currently compiled into cpp or a caller program and mean that
the user must rely on the result of the output of "strings" on cpp or cc,
and some guesswork, or hope that any changes are reflected in the
manuals on each release. I'd be much more comfortable in reading a file
such as /etc/local-system which contains
-Dmips
-DBSD4

etc, and having cpp doing something like
#!/bin/sh
/lib/cpp.real `cat /etc/local-system` "$@"

The inbuilt defines couldn't be clearer and there would be no need to
include any files that are unlikely to exist on other machines.
We currently use such a system to communicate some kernel changes
that affect the sizes of system structures to all the system
sources without having to edit them.