Dependencies / compatibility for 2.5 SP

[Cantor, Scott]

I know some packager-type folks monitor this list, this is mainly targeted
at them. People presumably saw my note to announce about dropping SLES 9
due to a dependency, I thought I'd elaborate and document my current plans.

The root issue is boost, which is a large collection of C++ template
libraries that have some of the features of the new C++ standard. I've
avoided using it because it's been a dependency hassle in the past, but
there's a lot of useful code in it, and I'm not going to be able to use
any of the new language features for years (if ever), so I'm taking a
fresh look at it.

Most of boost is actually just templates in header files. A few of the
components have runtime libraries, but I don't have any current plans to
use them. Avoiding those means it's strictly a build-time dependency, and
doesn't actually require any building itself. Even if it did need to be
built, it's substantially better than it used to be. The one caveat is
that in some cases, macports in particular, the packaging system does do a
build of all the pieces itself, and it is *slow*, like 20-30 minutes slow
on a decent laptop.

Aside from that, it hasn't been a big issue in my testing so far, with the
exception that the Linux distros are of course horrendously out of date.
That limits what I can do with it, but not to the point of uselessness.
The two features I wanted to use so far I was able to use on every
supported OS *except* SLES 9 (thus my note). Even Red Hat 4 has a new
enough version that I wouldn't break compatibility with it, despite my not
supporting it.

It doesn't complicate the build any, I have autoconf support working, and
adding boost-devel to the RPM BuildRequires is basically the whole change.
I'm going to try and find out what the Debian story is, but at a glance, I
think the version included with lenny was new enough. I doubt anything
farther back is.

If one needed to build by hand on an unsupported/old Linux, there isn't a
big problem, you just download the latest boost source and point configure
at it. I think that's reasonable for people to handle.

Windows of course is my problem anyway, but it's easy to use there.

Macports has a boost package that's current, and it works fine; only issue
there is the ridiculously slow build. I may look into creating a
headers-only boost package with no build.

So we come to the usual hitch in every plan, Solaris.

It works, sort of. I've been sidetracked because I discovered a bug that's
been there for a while, and that turns out to be unrelated to boost. At
this point, Sun's compiler is causing problems for some of my tests (it
builds, but the code crashes). I think I know how to fix it, but I've been
taking a fresh look at using GCC there. That used to not work so well, but
I suspect it works fine these days, depending on where you get it.

Related to this, boost does not support the non-compliant standard library
Oracle ships with the OS and that the Solaris Studio compiler uses by
default (libCstd). It does support the "stlport" library that is included
as an option. The hitch with stlport is that it doesn't come with the OS,
and has to be installed by hand separately if you don't install the
compiler on a box. It's just a shared library and it is redistributable,
it's just annoying.

Anyway, once I fix this code I found that their compiler isn't handling, I
think I can get things working with boost and the Sun compiler. The steps
involved for a deployer are not pleasant, but they're not that much worse
than today:

- download boost (no build step needed)
- point the relevant configure commands at it
- set CXXFLAGS to "-library=stlport4" (I probably can do this in autoconf)
- make sure libstlport.so is available at runtime
- don't mix in any code that's built against libCstd

The latter restriction means I lose support for Sun Java Web Server on
Solaris (I doubt anybody was using it, but it does work now).

Alternatively, boost works fine with GCC, so probably everything could be
built with that in place of Sun's compiler, possibly with less hassle, but
probably more variability in terms of whether any given system will run
into problems.

So that's the story at the moment. I would prefer that it not be such a
mess, but I'm also sick of writing my own code to do things boost has well
tested libraries to do for me. And I'm really sick of Solaris being the
cause of me having to do that when it all "just works" everywhere else.

Concerns?

-- Scott