Chris,
> You raise some good points.
> What would you recommend to resolve your issues?
> /usr/suncc/*?
in principle, yes, though I'm a bit confused about the suncc moniker. It
reminds me of Sun C Compiler, which doesn't seem to fit given that all of
C, C++ and Fortran are included. I suppose it is meant as Sun Compiler
Collection, just like GCC was reinterpreted from GNU C Compiler to GNU
Compiler Collection?
I'd have chosen /usr/studio/* instead, but given Sun Marketing's history of
randomly renaming products at least every other year (consider WorkShop,
Forte, Studio ...), this may be unwise.
> How should we anticipate the future possible parallel
> inclusion of SS12+patches? Perhaps /usr/sunccx for
> the latest express and /usr/suncc for the latest stable/FCS release?
I'd just use /usr/suncc/12.0 and /usr/suncc/13.0 (or omit the .0 part if
there are no and never will be minor releases), just as is done for all
other cases of parallel installations (like mysql, postgres, ...). This is
a model familiar to users. One might want to think about 13.0ea or some
such while Studio 13 isn't yet released to make users aware that they are
using an alpha/beta product, but that's about it. I don't think a solution
that only supports the latest stable version and express is enough. Many
sites may need to have more different version installed in parallel, and
using a different directory in /usr for each such version seems to
unnecessarily clutter that directory.
> I agree that the more normal convention for projects is /usr/XXXX.
> Do you think the creation of /usr/compilers is so confusing
> or different that the project should be forcibly prevented from
> using that path? (I'm trying to understand the scope of the issue)
It's just different from a well-established convention, and if there are no
very good reasons to deviate here, I'd strongly suggest to stay with the
convention. Familiarity helps users, and so far I've seen no strong
argument suggesting why this different convention (/usr/compilers/<micro
release>) is useful or necessary.
> Note: The rationale for multiple versions of gcc is
> very different than for Sun Studio compilers. I'm not
> trying to imply anything here about the GCC case.
Even in the Studio case, it is useful to keep more than two versions
around. At least our site currently does.
> Also Note:
> The case doesn't discuss how a parallel delivery of two
> compilers (EG SS12 and SSX) will be handled with regards
> to symlinks and default paths. That is still TBD at this point.
> The goal is for the symlinks to cause the "right thing" to
> happen by default for almost all Solaris developers.
> IE: You just automatically get a compiler that works.
> The only concession we've made is to put the symlinks into
> a separate package, but that's not really a complete story yet.
Maybe something can be learned from the JDK deliveries here? I don't know
the full story, but know that the JDK 1.5 and 1.6 packages somehow dealt
with setting a default.
In my opinion, the only sane solution is to have the latest stable version
as the default (i.e. in /usr/bin), and leave Studio Express to those that
need the new features/want to experiment. Solaris has a reputation to
loose for its stability, after all.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
