|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-05-26 10:26:09
"Robert Mathews" <rmathews_at_[hidden]> writes:
> And all programming shops I've been to pick a particular compiler,
> programming model, and then stick with it, so the following idea should
> work:
>
> So, what you'd do it is write a installer stub that
> 1) queried for compiler model
> 2) queried for compile model (single threaded, multithreaded, static, dll
> etc)
>
> And then took that information and went off and downloaded the correct
> library.
Probably that makes too many prebuilt libs for Boost to build, test,
make available, and support. I don't know of any open-source project
that supports 50+ platforms in 4 configurations with binaries.
> Seems simply enough to me. Much simpler than trying to recreate the UNIX
> auto-config behaviour on Windows, because Windows just isn't very robust
> that way.
Can you implement it? ;-)
>> The easiest way would be to have the installer auto-detect
>> compilers on your machine and allow the user to edit the list,
>> adding/modifying compilers as they need, then select which ones
>> they want to build the libraries for. It should be possible to
>> build again at a later stage when you add a new compiler, etc.
>
> That's precisely not the easy thing. It saves download time, but costs
> complexity, and worse, when things fail, they fail far away from the expert
> who constructed the auto-detect algorithm. So, you end out with a
> frustrated expert and a frustrated user.
The user will also have problems with prebuilt libraries when he tries
to use them in his project that has a different, incompatible
configuration.
> It's the customer support issue. You want to mimimize the complexity of what
> executes on the client, so that less can go wrong.
I think there are several sides to this polyhedron.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk