On Mon, Jan 12, 2009 at 10:21 AM, Rainer Orth
<ro at techfak.uni-bielefeld.de> wrote:
> I don't buy this
+1 - repeat as needed.
Rainer is raising extremely valid points that directly point at
architectural sloppiness and muddy thinking in these proposals.
It really sounds like someone has decided to create a /usr/compilers/
playground where the compiler team at Sun can stuff whatever private
copies of things they wish, without really dealing with the community
itself.
If micro versions of the GNU binutils need to go in this sandbox, why
shouldn't copies of the "solaris" as, ld, ... commands be put there
also? What happens if *they* change out from under the studio
compiler? Is this because you have different rules for Sun stuff -vs-
community stuff, you don't trust the community stuff, you don't put
the effort into understanding it, or ... ?
The path forward seems to be along the lines of
Update binutils in (Open)Solaris to the latest; it won't break anything.
This is exactly the same architectural mechanism that allows
us to update the OpenSolaris versions of as, ld, ar, ls, ... every two
weeks in Nevada builds - we trust that those things will evolve in
compatible ways. We are so sure of this principle that we don't even
bother to mark the components of these weekly releases with their own
explicit version numbers...
Provide an architectural proposal for /usr/compilers that addresses
Rainer's open questions such that the community (and not just Sun's
compiler group) can maintain things there. If this is truely a
*compiler* sandbox, where does Sun's Java compiler fit? etc etc etc
Provide sub-cases for the various compilers (including gnu3 as well
as gnu4...) that show how they will live and evolve in that sandbox.
How multiple versions will coexist, be used, etc.
-John
