"Andy Little" <andy@servocomm.freeserve.co.uk> 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