Path: utzoo!utgpu!cunews!micor!latour!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: comp.unix.admin Subject: Re: what kind of machine am I Message-ID: <1479@ecicrl.ocunix.on.ca> Date: 10 May 91 01:30:29 GMT References: <858@lhdsy1.chevron.com> Distribution: na Organization: Elegant Communications Inc., Ottawa, Canada Lines: 77 In article <858@lhdsy1.chevron.com> dlm@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, 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@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!