So I hear two issues here:

1. /usr/compilers is a bad name because it is too generic

Please suggest another name to give us an idea of what you're looking for.
I consider any reference to "Sun Studio" to be inappropriate because 
we're not delivering all of Sun Studio, or even all of the compilers
from Sun Studio.  Do you have other ideas for a good name?

2. The project should anticipate delivering multiple versions
of the compilers into Nevada, and/or the project should deliver
multiple versions as part of this case.

I think there has been a lot of discussion about this already,
I really can't think of anything new to say on this topic,
but I'll give it a try.

> This is extremely unfortunate, since it puts the burden upon the users to
> install different compiler versions in parallel.

I don't anticipate any user ever needing to create a pkg "user-image"
or use an alternate base directory to install any compilers.
I don't see a big burden here.  If you need different compilers
for different projects you'll need to add them to the system 
(using the normal default install steps) and remember which one to
use for which project.  That hassle is not made any better or worse
by this case.

Caveat: Our current unbundled releases install into a common
directory /opt/SUNWspro.  So to get SS11 and SS12 on the same
S10 system, you need to specify an alternate base directory to
the installer.  We're working on changing that so that the 
default install directories are different.  This should never
be an issue on an OpenSolaris distribution, but we haven't pushed
an FCS release there yet.

--chris




Rainer Orth wrote:
> Raj Prakash <Raj.Prakash at sun.com> writes:
> 
> Sorry for commenting so late, it almost fell through the cracks, and some
> of my concerns have already been voiced by others, but not really adressed.
> 
>> 4. Technical Description:
>>     4.1. Details:
>>
>>      - The design of the Sun compilers precludes just installing
>>        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
>>        installed in /usr/bin and /usr/share/man.  The delivery will
>>        install the bundled compiler collection components into
>>        /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and
> 
> Given that it seems that future GCC version will not be delivered into
> /usr/compilers, the name seems much too generic: this is not for all
> compilers, but exclusively for the Sun Studio (or whatever they are or will
> be called) compilers.
> 
>>        /usr/share/man.  We chose the name 'compilers' to
>>        intentionally indicate these are the
>>        default|builtin|preferred|bundled compilers.  There will not
>>        be multiple versions, there will 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..  Note Sun Studio also provides an
> 
> This is extremely unfortunate, since it puts the burden upon the users to
> install different compiler versions in parallel.  While at least with SVr4
> packaging, the compiler packages can be relocated via BASEDIR, AFAIK at
> least until now pkg(5) is incapable of doing so, leaving no way for the
> user to perform the relocation by himself.  To me, ample evidence has been
> provided that the parallel installation of different compiler versions in
> parallel is necessary, so leaving this to the user is just incomplete
> architecture.  Why is it so difficult to handle this requirement with the
> Studio compilers if many other packages manage just fine?  To me, this
> feels like a hack instead of real architecture.
> 
>>      - The first delivery will be the C, C++ and dbx components of
>>        Sun Studio Express 2008.11 release..
> 
> As I said before, I doubt this is wise: Studio Express is a fast-changing
> alpha/beta product which shouldn't be the default compiler set.  I know
> that SXCE/Indiana are alpha (or whatever) themselves, but we don't provide
> beta versions of, say, apache or gcc either.
> 
>>     4.5. Interfaces:
>>
>>         The following soft links will be created in /usr/bin to point to
>>         the appropriate binaries of /usr/compilers/suncc2008.11/bin.  We
> 
> This doesn't match what was specified earlier: to match, this should be
> /usr/compilers/bin.
> 
>>     4.10. Packaging & Delivery:
>>         Name                    Stability               Notes
>>         ====                    =========               =====
>>         SUNWcompilers           Committed               Sun Studio C/C++/dbx 
>> core cluster
>>         SUNWcompilerlinks       Committed               Sun Studio C/C++/dbx 
>> /usr/bin /usr/man links
> 
> Same argument as before: SUNWcompilers is far too generic.
> 
>       Rainer
> 


Reply via email to