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 [EMAIL PROTECTED] 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/
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
