Rainer,
I misnamed this ARC case, and it appears to be causing a significant
amount of confusion. This case should have been named Bundled Compiler
Collection. The intent is to bundle Sun compilers into /usr. We are
not bundling all of Sun Studio. This collection only contains C
and C++ compilers along with their debugger, dbx.
Given the design of the Sun compilers, we can not just install them
into /usr/bin, /usr/lib, etc. without significant redesign. We need a
location into which to install the compiler components, with symlinks
to those components in /usr/bin and /usr/share/man. So our original
intent was to install the bundled compiler collection components into
/usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and
/usr/share/man. We chose the name 'compilers' to intentionally
indicate these are the default|builtin|preferred|bundled compilers.
There would not be multiple versions, there would always and only be
one set of bundled compilers. Versions of the unbundled Sun Studio
will continue to install into /opt, i.e. /opt/sunstudio13,
/opt/sunstudio14, etc.
As it happens there was some amount of miscommunication and the
LSARC/2008/776 GNU Developer Collection case was submitted installing
into /usr/compilers/gcc432. So we adapted our misnamed case
(LSARC/2009/017) by choosing to install into /usr/compilers/suncc2008.11.
As our ARC case sponsor has noted, we will update our proposal and
start anew.
Regards, Douglas
Rainer Orth wrote:
> 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
