Darren J Moffat writes: > James Carlson wrote: > > That one is still murky. If there are no highly-fluid dependencies on > > the rest of ON (i.e., vast tracts of private interfaces that change > > frequently), then there's nothing that binds ksh to ON. It would seem > > to have a much greater affinity to SFW, as that's where it's generally > > acceptable to have your own non-ON build style, use non-default > > compilers if you want, do testing right in the middle of the build > > process (rather than in the test gate where it belongs), and so on. > > The fact that this cases intends to add the b_*() interfaces into libcmd > seems to indicate that it might need to be in ON or the existing libcmd > needs to move out of ON. You can't deliver parts of a library from two > separate consolidations.
One could reasonably move libcmd out of ON along with ksh. That's essentially what I assumed, as the only other interfaces there are Sun Private, highly static, and trivial. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
