what kind of machine am I

[Chris Lewis]

In article <858 at lhdsy1.chevron.com> dlm at lhdsy1.chevron.com (Dennis L. Malefyt) writes:
>Problem: we want a unique and simple way for a user/developper to
>determine what type of machine he/she is on. What we are interested in
>is the binary compatibility, not the model number, amount of RAM, etc...
>of a particular machine.

>Solution: is two-folded.
>	a) we need a database of significant names
>	b) we need a mechanism to get the appropriate name.

You have to consider two scenarios: if the machines are under your control,
you'd be best off creating a file (such as was mentioned elsewhere) that
contains your configuration/compilation keys.  On the other hand, if they
aren't under your control (eg: your software has to build on "virgin"
systems that you don't support), you can do something like we did:

We have some software that automatically compiles itself "correctly"
on at least 30 platforms (from archaic Xenix systems thru many
flavors of System III, V, AIXes, Irises and BSD-derived machines).  The software
is inherently rather "systemy", so there are a LOT of differences we
have to intuit.

I implemented a shell script that attempts to figger out what machine
the software is being built on, and it places the name into a file, plus
occasionally other special flags.  The makefile encorporates this in 
the build procedure as a -D<machinename>, and the main .h file has a lot
of ifdef's.  Rather than try to identify commonality amongst different
platforms, we simply key on the machine type on the places where dependencies
arise - both in C code, and in shell scripts.  There is, unfortunately, no
common method to do this.  The shell script looks at the following things:
	1) Many systems have "/bin/true" and "/bin/false" linked
	   to several "machine type names".  Ie: on my 3b1:

   85 -rwxr-xr-x  2 bin     bin          33 Jan  1  1970 mc68k
   85 -rwxr-xr-x  2 bin     bin          33 Jan  1  1970 true

   76 -rwxr-xr-x  5 bin     bin          42 Jan  1  1970 false
   76 -rwxr-xr-x  5 bin     bin          42 Jan  1  1970 pdp11
   76 -rwxr-xr-x  5 bin     bin          42 Jan  1  1970 u370
   76 -rwxr-xr-x  5 bin     bin          42 Jan  1  1970 u3b
   76 -rwxr-xr-x  5 bin     bin          42 Jan  1  1970 vax

	    I have a loop like this:
		for i in mc68k pdp11 u370 u3b vax sun3 sun4 mips 4d
		do
		    # arg!  Old Bourne shells don't support -x!
		    if -f /bin/$i
		    then
			if /bin/$i
			then
			    machinetype=$i
			    break
			fi
		    fi
		done

	2) Many systems also have a "uname" that you can intuit
	   a type from (this is how we detect AIX in it's three main
	   flavors)
	3) Some machines have files that are unique to them.  Examples:
	       - Dynix (Sequent) has it's kernel in "/dynix".
	       - 3b1's have a /etc/lddrv directory (but so does Unisys's
		 386 platforms, but we can disambiguate by other features)
	       - Most SVR3 386 platforms have /etc/conf etc.
	       - NCR Towers have /etc/RELDEF and /etc/SYSIDENT

You have to validate your software on each platform you port to, and at
that time you can figger out how to disambiguate it from other flavors
for autobuilds.  This works well enough for us that we can uux a tar image
of the source tree to a remote system and have it build and install correctly
without human access to the machine.  Without having to know what platform we're
uux'ing it at.
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis at ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!