|
Boost : |
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-04-17 02:41:05
"Walter Landry" <wlandry_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk