Torrey McMahon wrote: > 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?
There is no "default path" because this is a bundled component, the path that we choose will be hard-wired for this delivery of the bits. It was probably a mistake to use "Sun Studio" in the name of this ARC case, because the delivery is separate from the official "Sun Studio" product per-se. The answer to your question is yes. The impact is this: If we want to support parallel delivery of multiple versions of Sun Studio Express, then we'll need to use a version specific name for the path. The same decision applies to parallel install of SS12 and SSX. The case proposes to use a fully-distinguished path (including version number). This leaves our options open to support parallel installs in whatever form we choose without committing us to do so. Any feedback for or against parallel installs of Sun compilers would be appreciated. Might we want both SS11 and SS12 in Nevada at the same time? Or in Solaris 10? --chris > > 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 >>> >>>
