[3031] in SIPB bug reports
gnuserv not installed properly in sipbsrc
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Sun Jul 12 14:53:56 1992
Date: Sun, 12 Jul 92 14:53:21 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: yandros@Athena.MIT.EDU
Cc: bug-sipb@Athena.MIT.EDU
In-Reply-To: yandros@Athena.MIT.EDU's message of Fri, 10 Jul 92 13:43:57 -0400 <9207101743.AA08786@hodge>
From: yandros@Athena.MIT.EDU
Date: Fri, 10 Jul 92 13:43:57 -0400
Reply-To: yandros@Athena.MIT.EDU
X-Orgs: MIT SIPB IS-CSSC IS-DCNS
I can see your point, Jik, but I'm not convinced that we really need
to use space for full trees for all platforms. When I built something
in the locker, I installed stripped binaries and left fully populated
build trees in sipbsrc, for a week or two. When things seemed fine
after that, I did a make clean; leving the Makefiles set up to build
correctly with a simple 'make' (this is important, since I had to
hand-edit the Makefiles on some platforms.) I see nothing wrong with
this, although I really don't see anything wrong with leving populated
build trees around while we have space...
1) I hope you don't mean that you left architecture-specific Makefiles
in the build directories without propagating the changes you had to
make to them back to the source tree. WRONG. The build trees are not
backed up. ALL data that should be preserved should be in the source
tree, not the build trees.
If you need to hav different Makefiles for different platforms, then
you should convert the Makefile into a Makefile.cpp or Imakefile and
build it for each platform.
See, for example, arc/Makefile.cpp.
2) "A week or two" is not enough time for problems in programs to show
up. I have often had to track down bugs reported months after
programs were installed in the sipb locker.
I don't understand why this is so controvertial. WE HAVE THE DISK
SPACE. As long as we do, there really is no reason NOT to keep the
build trees along, and it DOES save us time in the long run.
jik
