Rainer, You raise some good points. What would you recommend to resolve your issues? /usr/suncc/*?
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 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) 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. 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. --chris Rainer Orth wrote: > Raj Prakash <Raj.Prakash at sun.com> writes: > >> 4. Technical Description: >> 4.1. Details: >> - Existing C, C++ and dbx components of Sun Studio Express >> 2008.11 release will be installed in >> /usr/compilers/suncc2008.11 similar to LSARC/2008/776 GNU >> Developer Collection > > I've the same objections here as I've raised for LSARC/2008/776 (many of > which haven't been answered yet): > > * Where's the need (or precedent) for the deep nesting with > /usr/compilers/suncc2008.11? All other cases use (say) > /usr/suncc/2008.11, as I've mentioned several times before. > > * Where's the need for this level of granularity. If the plan is to > integrate successive releases of Studio Express, I cannot see a reason to > have them installed in parallel (I see them as similar to Studio 12 + > Patches, which aren't installed in parallel either). On the other hand, > this creates a usability problem: if the intention is to install > different versions of the Studio compilers in parallel (which certainly > makes sense e.g. for Studio 12 + Studio Express), the user is not > generally interested in which particular delivery (or patch level) of the > Studio tools he is using, only in the distinction between Studio 12 and > Express. If he wants to specificially select Studio Express when Studio > 12 is installed as well, in the proposed scheme he has to update his PATH > every time a new delivery is included (which could be as often as every > three months), instead of selecting Studio Express vs. Studio 12 once. > > Rainer >
