There has been a thread running with the subject "[system] Why is this not header-only?" that discusses header-only versus compiled-library compilation models for Boost libraries. Some users require the compiled-library approach. I'll characterize these folks as requiring the shorter compile times and better software engineering practice that compiled libraries provide. In some cases these folks have had to rework Boost header-only libraries to create compiled libraries. Some users prefer the header-only approach. They need to be able to quickly set up at new project without messing around with compiled libraries. They want to be able to evaluate Boost libraries without doing any preparatory work altogether. Jeff Garland and Andrey Semashev argued that Boost should adopt a hybrid compilation model that allows applicable Boost libraries to be used in either header-only or compiled-library modes. Note that Boost.Test already provides this, although with degraded functionality in header-only form. There was some discussion as to how to do this; my eyes glazed over when discussions drifted into problems of dlls, singletons, etc. I'll like to challenge Boosters to think about this problem a bit more, and I'd love to see someone who understands the challenges take, say, Boost.System and demonstrate how it could be packaged for either header-only or compiled-library use. The important goal would be to abstract what to done into a general set of guidelines (and any configuration support needed). In other words, we don't so much need a solution for Boost.System as for any Boost library that would benefit from a hybrid computation model. Comments? --Beman