On Tue, Jul 21, 2009 at 05:31:13PM -0700, Chris Quenelle wrote:
> I see that SUNWsprot (which contains make/sccs/assembler and the
> new profile support library) is listed as developer/tool/sun-make-sccs.
>
> Is there some logic to the grouping of "developer/tool/*" ? What makes
> something a "tool"? It seems to be used as a synonym for "misc" or "other".
The package list is by no means finalized. It might make sense to go
through the exercise of splitting up some of the packages that will be
split (like SUNWbtool, SUNWtool, and SUNWsprot) and seeing if there are
other patterns that show up. But /developer/tool isn't set in stone, and
if we want to have /developer/make, /developer/sccs, /developer/as, etc,
there's nothing wrong with that.
> It seems like "developer/c" is not the best container for gcc, since that
> package also contains fortran and C++ compilers. Perhaps
> developer/compiler/gcc would be better?
The gcc package may undergo a split itself, in which case, gcc and the C
backend could go in /developer/c/gcc, and g77 and the fortran backend would
go in /developer/fortran/g77, etc.
> With those ideas in mind, perhaps the Sun Studio packages could be:
>
> developer/
> tool/analyzer
> debug/dbx
> ide/ss-netbeans
> tool/dmake
> misc/sunstudio
ss-netbeans and dbx seem right; I'm don't care one way or another about the
"tool" subcat so those could go there or directly in /developer, and I
guess "misc" is as good a place as any for the common studio packages.
Could you describe a bit more what goes in that last?
> developer/compiler/
> c
> c++
> fortran
> backend
> perflib
> perflib-interval
> scalapack
Seems fine. I don't have a strong opinion about grouping all the compilers
in a suite together, rather than splitting them up by language, but either
would work. I'm dubious about the up-leveling of the components here,
though (without a "sun" or "studio" in the middle). Note that you'll be
able to refer to a package by its smallest unique subcomponent, so you
could still run "pkg install c c++", even if that expanded to
/developer/compiler/studio/{c,c++}. I don't know if that's a sufficient
compromise for your marketing folks. I agree it's not terribly confusing,
but it's a bit presumptuous, and, IMHO, gratuitous.
I assume "backend" is a common package that all the others would depend on?
> library/
> c++-libs
> fortran-libs
> math-libs (or libsunmath)
> perf-libs (or libsunperf)
> scalapack-libs (or libscalapack)
I'd lean towards the lib* forms, mostly for consistency with other (FOSS)
library packages, which are likely to be referred to in that way.
> The idea behind the name "c++-libs" is not that it contains all or most
> c++ libraries, it's a package of runtime libraries released with the C++
> front end, by the same team. They're not terribly co-dependant, as far
> as I know. I wasn't going to split out libstlport from libgc and
> librwtool.so etc.
How will the standard C++ libs (libC, libCrun, libCstd) be handled in the
new world? Is it possible to start delivering them once, rather than both
here and in SUNWlibC (or whatever that package gets named)?
Danek
