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. -- Darren J Moffat
