Doesn't the method by which you deal with parallel delivery of packages, be it gcc or sunstudio, and any linking impact the install location and default path?
On 1/12/2009 2:28 PM, Chris Quenelle wrote: > 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 >> >>
