|
Boost : |
From: Amanjit Gill (amanjit.gill_at_[hidden])
Date: 2002-02-25 15:39:57
-----Ursprüngliche Nachricht-----
Von: ross_at_[hidden] [mailto:ross_at_[hidden]] Im Auftrag von
Ross Smith
Gesendet: Montag, 25. Februar 2002 06:18
An: boost_at_[hidden]
Betreff: Re: [boost] About installation
Hello..
>The problem is not installation by developers. That's awkward but
workable now. The problem is
>installation by END USERS who wouldn't know an include path from a hole
in the ground. ><Expecting users of our software to go through anything
as complicated as the above is _way_ ><beyond the bounds of reason.
I think right now a library such as boost is intended for developers _in
the first place_, and due to the nature of this process (it is very
dynamic and has to be flexible) one should avoid every unnecessary
lock-in to tools, setup scenarios / platforms etc.
The enduser right now _is_ the developer. And he can fully benefit from
the current scenario.
As long as a library is still evolving or at least parts of it, people
should *explicitly* use it - software developers - and know what they
are doing.
It would really increase the complexity of the boost evolving process to
start bundling distribution packages in any form (rpm, msi) _by default_
. Boost would have to cope with the normous configuration, installation
and platform-specific issues that would automatically arise when
different versions of libraries would be around and end-users and the
software they use would actually depend on that. The endusers of that
software would come around and complain why their configure script fails
(or worse).
People (endusers using software) should not *implicitly* depend upon it
_right now_.
Please do not misunderstand me, I do not have the opinion that boost is
anything like beta or broken (I do not _understand_ all aspects of the
library to judge that at all) or not mature but it think it doesn't make
sense to add complexity and lose energy/time on a dynamic process.
Just my 2 cents,
_____________________
Amanjit Singh Gill
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk