[2297] in Release_7.7_team
re: Sun compiler update
daemon@ATHENA.MIT.EDU (oliver thomas)
Thu Jun 1 17:49:13 2000
Message-Id: <200006012149.RAA38306@mufasa.mit.edu>
To: Alex T Prengel <alexp@MIT.EDU>
Cc: owls@MIT.EDU, release-team@MIT.EDU
Cc: oliver thomas <othomas@MIT.EDU>
Reply-To: oliver thomas <othomas@MIT.EDU>
Date: Thu, 01 Jun 2000 17:49:10 -0400
From: oliver thomas <othomas@MIT.EDU>
hi alex,
> These new compilers have been around for about 6 months (in the
> sunsoft_v6.1 locker) and I haven't heard anything about them from
> anyone; of course I don't know if anyone has been using them.
i don't recall any questions in the queue specifically about the new
compilers, but if you'd like data i can ask one of my students to go over
the last six months of C topic questions looking for some.
> The update can be done "invisibly" by switching an AFS link,
> /afs/athena/software/sunsoft, to point to sunsoft_v6.1 instead of
> sunsoft_v5.1. As this will affect everyone on Athena using Sun
> compilers, I need to know when it's a good idea to do;
from a consulting point of view, sometime in late june or early july would
be good since that is a time when we are not very busy and any programming
projects relying on the sun compiler are in a non-critical phase (mostly
we run into end of summer deadlines for these things). i guess that's the
same rule we use for most 3rd party software updates.
> the one major issue is that there is no pc in the new release- rather
> than trying to symlink back to the sunsoft_v5.1 locker from sunsoft_v6.1
> for pc, I think the attach-and-run pc script in the release could be
> changed to attach the sunsoft_v5.1 locker instead of the sunsoft
> locker. What do you think?
how about putting a shell script called pc in the _v6.1 bin directory
which displays a message about pc no longer being a part of the 6.1
version of the compiler, and instructions on how to access the older
version compiler.
i think in general i prefer educating users about version changes while
giving them the option to use an older version and keeping the actual
software as close to the vendor package as possible, over introducing
version dependencies into attachandrun scripts and locker symlinks.
the attachandrun script in the release is relatively hard to change and
keeping track of a version dependencies there will be difficult. from a
support standpoint, having the user find out that a program they are using
no longer exists in the new version of the compiler software seems
acceptable as long as the old version doesn't go away.
what do you think?
oliver
