Keith M Wesolowski wrote: >On Fri, Apr 28, 2006 at 04:40:03PM +0100, John Rice wrote: > > > >>optimization, which is good. However, that's not the issue. The problem >>is really down to the various build tools or lack of them on Solaris >>that OSS just expects to be there on a Unix box if it is to be able to >>build with out lots of hair loss on the part of the user. >> >> > >The problem is really that people, for reasons of ignorance or malice, >write nonportable software and fail to document it as such. >Ironically the FSF is actually very good about portability most of the >time, despite their goal of replacing and eliminating all other >operating systems. Others simply assume all the world is running >GNU/Linux. Well, that's their right - they did the work, and if they >don't want you running their software on OpenSolaris, they aren't >obligated to help you. If we want people to be able to use this >software, it's up to us to fix it on the platform we love. > > > >>It would be great to solve this - if we are serious about really making >>Solaris rock as a developer platform I think we have to. >> >> > >It already does. A lot of your suggestions seem to equate "good >development environment" with "looks, feels, acts, and sounds exactly >bug-for-bug and feature-for-feature compatible with a hypothetical >common GNU/Linux distribution." We can help people who want that by >delivering /usr/gnu; add that to your path first and you'll feel a lot >more at home (and /usr/gnu, unlike /usr/bin, could contain unprefixed >names of the familiar utilities). This is just like /usr/xpg4 and >friends - your path determines the standards personality you see. > > > >>Is the solution to include the current JDS Common Build Environment - >>has all of the GNU/ Apache build utils like automake, autoconf, >>libtools, make, ant ...? >> >> > >Absolutely not. The JDS "CBE" (which is curiously named since it's >actually not common at all but specific to JDS) is an unholy >amalgamation of stuff that's already in OpenSolaris, stuff that's in >the Companion, and other stuff, but with different versions, different >configuration options, and no architectural review. >
That's a pretty ambigous paragraph. E.g. the Companion also doesn't have architectural review. >That's unfortunate for a build environment, but it would be catastrophic in >shipping products - be they Solaris or any other distribution. > > In sorting this out, it really doesn't help to conflate supported shipping things (e.g. Solaris 10) with un-supported shipping things (e.g. Solaris 10 Companion), and un-supported, non-shipping, things (e.g. Nevada consolidation and build environment downloads). -Eric >>1) Add Free Software development tools currently not shipped with >> Solaris. This includes automake, autoconf, libtool, cvs, etc. >> >> > >All of this is in the Companion already. It needs some TLC, but you >could ARC it and put it in SFW. Not that I want to encourage anyone >to use these tools, but we shouldn't prevent it either. > > > >>2) Many commands in the CBE are replacements for existing apps >> in Solaris. Examples include make, diff, m4, flex. We should >> work with the Solaris team to enhance the Solaris versions of the >> tools so we don't need to ship an extra GNU version of the tool. >> >> > >Sure, when possible. But /usr/gnu would make that a lot less >important. > > > > -- > Keith M Wesolowski "Sir, we're surrounded!" > Solaris Kernel Team "Excellent; we can attack in any > direction!"
