[2602] in Release_Engineering
Athena, UCSC and PANSS
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Mon Jun 3 20:54:04 1991
Date: Mon, 3 Jun 91 17:52:45 -0700
From: "Jonathan I. Kamens" <jik@cats.UCSC.EDU>
To: rel-eng@ATHENA.MIT.EDU
Cc: haynes@cats.UCSC.EDU, sun-athena@cats.UCSC.EDU
As most of you probably already know, I am working at UCSC this
summer, helping them out with there Project Athena installation on Sun
workstations.
However, I do not expect the work that I am doing here at UCSC to only
be applicable here at UCSC; I expect to take much of it back to
Cambridge with me when I come back in the fall (figuratively or
literally) and integrate it back into our source tree. I'd like to
explain my intent and get some input from others at MIT about what
might make my life easier while I'm actually doing the work.
Since I have been given the responsibility of organizing the PANSS
tape, one of the things I would like to achieve this summer is to make
the sources in the Athena source tree directly transferable to that
tape. In other words, if I want to put kerberos onto the PANSS tape,
I want to be able to type "cd /source/athena/athena.lib; tar cvf -
kerberos" and feed the output directly onto the tape (or whatever). I
don't want to have to copy the sources somewhere else and frob with
them to get them into the correct state.
In fact, the first thing I did when I got to UCSC was to tar the
entire source tree (without tokens, so I wouldn't get any of the stuff
that we're not allowed to distribute) and copy it over to UCSC.
That's the kind of thing that I want to be able to do to create the
PANSS tape (although some sources, such as X11R4, emacs {other than
the patches to make movemail do kerberos and such} and tex) will
probably be omitted.
Now, reading over the documents in /source/control/doc, it seems to me
that you've gone a long way towards achieving this, by Imake'ifying
the source tree. Imake will make the tree easily customizable for
other environments, which means that people can modify the Imake
templates in order to build things, rather than modifying the sources
themselves. Is there anything else you've done to make the source
tree easy to build on multiple platforms that I should know about,
i.e. stuff that isn't mentioned in /source/control/doc?
One of the things I'm concerned about in this effort of mine is that
many of the directories that we want to build when doing the build at
Athena will not be built when the sources are shipped out as the PANSS
tape. For example, /source/bsd-4.3 will not be on the PANSS tape, but
/source/Imakefile needs to know about it in order to build it.
Therefore, I propose to introduce a new Imake configuration symbol,
something like AthenaLocal (any better suggestions), which will only
be true when we are compiling for the Project Athena release at MIT.
I will be able to use that symbol to determine in Imakefiles whether
to use a full list of subdirectories or just the list of
subdirectories that will be on the PANSS tape. Does this seem
reasonable to people? Are there any suggestions for better ways to
accomplish this?
Athena has recently put a lot of effort into making the RIOS a
supported platform. I believe that the work that was done in that
case bears directly on what I will be doing here at UCSC, becauase
what was done on the RIOS is very similar I intend to do. In
particular, you are working with vendor binaries without recompiling
all of them for the release, like you do with the Vax and RT releases.
I would be very interested in knowing the process you went through to
achieve the RIOS port. Also, what kind of plan have you developed for
turning a standard IBM RIOS configuration into an Athena workstation
configuration? That's of special interest to us here at UCSC, because
we need to figure out how to do that with the Suns.
That's about all for now. Thanks in advance for any input you can
provide.
Jonathan Kamens jik@CATS.UCSC.EDU
