Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!sdcsvax!sdics!wallen
From: wallen@sdics.ucsd.EDU (Mark Wallen)
Newsgroups: comp.unix.wizards
Subject: sources in a heterogenous enviroment
Message-ID: <390@sdics.ucsd.EDU>
Date: Wed, 19-Aug-87 18:31:37 EDT
Article-I.D.: sdics.390
Posted: Wed Aug 19 18:31:37 1987
Date-Received: Sat, 22-Aug-87 04:48:14 EDT
Organization: Institute for Cognitive Science, UC San Diego
Lines: 55

With all the discussion about how to handle binaries
for different processors in a heterogenous NFS environment,
I have a related question.  How do you folks handle
your source files?  For instance, we've got a fair
amount of home-growed software and keep much of it
on a NFS partition.  So far so good; I've won on
both disk space and having to worry about multiple
versions of source (there's only one now).  Here's
the dinger--if I had just done a "make install" on
my Vax system and turn around and to a "make install"
on my Sun, there are probably a lot of Vaxish .o
files hanging around.  Sure confuses make and the
Sun loader.  The only safe thing to do is "make clean"
and start from scratch.  This is a drag.  One
solution that seemed feasible to me was to hack
the makefile and add SUFFIXES like .vo for Vax
.o's and maybe .10o, .20o, and .4o for the various
sun flavors.  Then have parallel OBJS type definitions
and targets for the different machines.  Is this more
trouble than it's worth?  It does let me do development
on both/all machines at the same time without having
to recompile the WORLD each time a make a change to
a single .c.  If it's been done, is there a consistent
naming scheme (i.e., what do you call the vax objects,
etc).

Another different solution also occurred to me and
kinda helps the multiple binary problem.  How about
different manufacturers have different A_MAGIC
numbers for their a.outs.  Someone (Sun, AT&T, me :-)
could referee the assignment of those numbers similar
to the way Xerox doles out Ethernet numbers.  The advantage
is that you won't be stumbling over the wrong kind
of binary--it's not an a.out on this machine.  "file"
could know that it's a Pyramid, Gould, or Vax binary
just by looking at the magic number.  It would break
some things, but I could imagine a transition period
where the kernel and few concerned utilities recognized
both the old 0407 numbers and the new ones (and always
produced the new, of course).  (Perhaps the old 0407, 0410,
etc are just a bit worn out--they were different versions
of the PDP-11 branch instruction to jump over the rest
of the a.out header if you tried to directly load and
execute an a.out).

Thanks for listening, er, reading.

Mark R. Wallen

Cognitive Science
UC San Diego

{ucbvax,decvax,ihnp4}!sdcsvax!sdics!wallen.uucp
wallen%sdics@sdcsvax.ucsd.edu
wallen@nprdc.mil