"Robert Mathews" <rmathews@envoyww.com> 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