Boost logo

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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at