From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-05-25 13:47:43
Robert Mathews wrote:
>I've been following this thread for a bit.
>I think that the boost community would do well to do the following:
>- precompile boost for Windows compilers
>- package up the headers and .libs in a MSI installation script (or some
>other native windows installer)
>- provide that for download
The problem is that each compiler adds several hundred megabites to the
install, so supporting VC6 (which patched version?), VC7, VC71, VC8 (which
beta/CTP?), BCB5, BCB6, CodeWarrior 8.x/9.x, gcc (which version??) you will
end up with an install that is on several DVDs!!!
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
Granted, this could make the install take a long time (if you are supporting
many different compilers), but the user should be able to (optionally) see
the output and provide a way of estimating how long the build phase will
take (so the user knows that they can come back in an hour or whatever).
An installer like ths could be intelligent enough to extract and/or build
only the ilbraries you want, for example, you could just build the
>That way we sidestep the whole issue of using JAM. This has two benefits:
>- Windows programmers expect to be able to click on a link and simply
>download the answer.
>- Windows programmers would get a reliable library that was built under
>controlled circumstances. We'd all spend less time supporting folks who
>trouble driving the compiler via JAM, and/or who have somehow produced a
>corrupt boost library.
What if you install a library for VC6.5 and you only have VC6.0? Building a
project could then break when you link against the 6.5 versions.
>Personally, I did use JAM successfully, but I also encountered a number of
>error messages that I quickly worked through, and didn't think much about.
>It would have been a barrier to someone less experienced though, and we
>don't want that.
The install/build GUI could process this so that it generates a friendlier
summary informing you of what broke.
Reece Haston Dunn
Software Engineer, Sophos
Sophos - protecting businesses against viruses and spam