From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-04-16 18:54:34
"Andy Little" <andy_at_[hidden]> wrote
>> well if you run RedHat Fedora Linux distro you get the boost rpms
>> automatically :)
>
> I was thinking more in terms of a finer grained system, whereby each
> library in
> the boost distro comprised a separately installable package
> r.p.m has has the right sort of functionality . Unfortunately I think it
> has the wrong type of licence.
I do not understand this concern. Any installer-builder I know can be used
as long as the
developer has licence to use it. AFAIK tools for building rpms are free to
use on Linux.
On other platforms somebody with the right lisenced tools may need to build
the installers,
then they can be distributed from the boost web-site. This is kind-of-like
using gcc or
vc++ for generating libs from your own source. The output is your property.
I think there are a lot of good installers out there, some are even
multi-platform.
Like bjam :) -- some may be easier to use, but "easy" here, depends on the
perspective
of the user. Windows users typically expect something that feels like
InstallShield; nothing
prevents having bjam hidden behind something that looks like a normal
installer. TrollTech
does that when their windows installer builds Qt on windows using their
makefile generator
called "qmake". I think building boost against the compiler on the
installation machine is a
good thing.
The problem is not to get boost installed, the problem is to make developers
realize the benefits of using it, and to avoid scaring them off in the
process. I agree
that a clumsy installation procedure may scare some potential users off, but
to be
honest I do not think that is the biggest obstacle for potential new boost
users.
My experience installing boost the first time was quite pleasant even if I
had to learn a
few things about a tool called bjam and get it installed first. I later
learned that it came
as rpms, but I have never tried to use boost as installed from the rpm. For
users used
to tools like yum, rpms are very easy to install if they are available.
So what are the real obstacles:
1. Managers acceptance of introducing a new tool
2. Convincing other developers on your team
3. Lack of consistant documentation
4. Lack of consistant support of all platforms (to me Sun CC support has
been a problem)
5. Lack of a good measure of the stability of the API of various boost
libraries
I feel like no. 5 is a real concern the boost team could do something about
with little
effort. You do not feel secure that the next version of boost will support
your code,
thus you feel like it may be risky to stick your neck out. Some clear
statements of which
libraries was considdered to be stable would be very nice.
regards,
Bjørn Roald