Hi, There's been some discussion in the JDS team about the problems with building OSS on Solaris, prompted by a recent somewhat derisory if deserved comment on Slashdot :(
Generally it's not a happy experience. From a speed standpoint there is no appreciable difference in compiling on Solaris if you are using the Sun Studio compilers and the GNU compilers with the same level of 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. I've gathered some thoughts and opinions from Brian Cameron, laca <lazlo.peters> our build maestro and others to get the discussion going. 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. So let the flames begin ;) JR P.s. Excuse the cross posting but thought both groups would be interested. How to make it easy to build OSS on Solaris? ---------------------------------------- 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 ...? laca>> I'd prefer to fixit at thesoruce and come up with a policy for GNU compatibility in Solaris. There have been efforts for that in the past[3][4]. Now that [4] is becoming history, we need a new policy to replace it. Joe Kowalski should be involved in any discussion about this. Brian>> 1) Add Free Software development tools currently not shipped with Solaris. This includes automake, autoconf, libtool, cvs, etc. 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. laca>> Some of these tools are already included in Solaris, under names like gmake and gm4. Many community Makefiles and configure scripts hard code the 'normal' names of these utilities so the GNU versions, although included in Solaris won't be used. That's why the CBE includes them again and puts them first in your PATH. 3) If we can't do #2 for certain tools, we could work to patch the code so it works with the Solaris tools and does not require GNU specific extensions, etc. I'd expect such changes would be not hard to get back into the community. laca>> Some of these tools have Solaris equivalents, e.g. diffutils (GNU diff) and fileutils (GNU ls, cp, rm, ...). The Solaris versions usually have much less features and different (or limited) CLI. Bringing the Solaris tools up-to-date with the GNU tools is either a) not possible because of conflicting command line semantics; or b) huge [wasted] effort, since these are already implemented by the GNU people [1] In this case it seems easier to include duplicates in Solaris.[2] [1] It seems that GPL code in ON is considered dangerous and instead people reimplement the GNU algorithms instead. [2] I had a similar issue with the gettext tools (namely xgettext and msgfmt) and I suggested using a wrapper that unifies the CLI and calls the appropriate version of the utility (Solaris or GNU) depending on an env variable. The responsible engineer preferred [1] and estimated that it would take him 3 months to implement... :/ [3] http://sac.sfbay/PSARC/2000/488/ [4] http://sac.sfbay/PSARC/2001/313/
