[1192] in SIPB_Linux_Development
Moving AFS out of project.sipb-athena
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jan 8 21:15:55 1996
Date: Mon, 8 Jan 1996 21:15:31 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: sipb-athena@MIT.EDU
Cc: probe@MIT.EDU
Okay, given what's been said here, I'd like to move the AFS source out
of the sipb-athena source tree, for the following reasons:
* Its build system cannot be easily automated from a top-level
Makefile.
* According to John Kohl, it's less work to have a single AFS
build directory for all architectures.
* The AFS build system is dependent on its revision control
system.
To complicate the issue, probe has an /afs/sipb/project/afs, with a
separte set of acls (probe:afs-read and probe:afs-write instead of
system:afsread and system:afswrite) and with multiple source
directories but a single build directory. We can either:
* Move the AFS sources into /afs/sipb/project/sipb-afs with a
version number of "3.3a-sipb" or something, and split the
existing build directory up by version number. I side with
this approach right now.
* Create a different volume with an artifically different
name (like /afs/sipb/project/sipb-afs).
As for cleanup, if you look in some part of /mit/afsdev/src
(e.g. /mit/afsdev/src/3.3a), you normally see directories "doc",
"rcs", and "src". By contrast, in our source directory you have to go
into "athena" (avoiding "pkg"), and then inside "athena" is "src",
"rcs" (a symlink to "rcs-new"), and a whole bunch of auxiliary
scripts, gzipped diffs, tar files, and other stuff which doesn't
belong in a source tree.
If the AFS source isn't going to be in the sipb-athena tree, it's not
as critical to do the cleanup, but we really should have something
cleaner.
