"Walter Landry" <wlandry@ucsd.edu> wrote
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.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case. I would expect a binary installer on Windows. In fact, there should be a list of binary packages on the front page. If they don't exist for a platform (OS X?), they need to be built and offered there.
I do agree with what you write, I do not think our wievs are that different on the installers, I was just pointing out that for me bjam worked fine and that I do not think installation is biggest hurdle to jump for potential users. I may be wrong. However on Linux people expect both the configure, make, make install and the packages for their distro. I guess developers should be happy with building. configure -- could do what configure does, option for installation root other than /usr/local make -- could build bjam and call it to build boost make install -- could install by calling the appropriate command in bjam Does not seem to hard to pull this off, I for one would not have considdered using autoconfig and friends on all of boost when you have boost jam unless there are platforms bjam will not support. But I do not considder myself an expert on this. One concern I have