/* snip */

I would actually prefer the non-header-only libraries to still be completely header based, but have the cpp implementations in filename_impl.hpp instead. Still have cpp files, but they just include the _impl version of the header, therefor projects that want to use the library side can link to it, or they can build it internally just be linking the _impl versions. This is how I handle my libraries and it works very well. Do note, some things should generally always be external libraries (Boost.Python), except for rare circumstances (like Boost.Python when embedding Python in your app).

On Tue, Feb 2, 2010 at 9:34 PM, Vicente Botet Escriba wrote:

Sachin Garg wrote:

...

On Tue, Feb 2, 2010 at 6:43 PM, Vladimir Prus wrote:

...

Sachin Garg wrote:

...

Header-only libraries are great as that eliminates the need for building the libraries and then linking with them. But not all libraries in boost are header only, which is an inconvenience.

Is this only because of 'legacy', and with time all libraries will move towards being header only? Or is there some technical requirement due to which some libraries just can't ever be header-only?

This question was discussed on Boost mailing lists at depth. Have you searched for those prior discussions?

Can you please provide link to that thread?

I tried a few google queries but they didn't show up any in-depth discussion. THIS thread in on first page for "boost header only" (without quotes) and some others I found discuss only which ones are header only and which ones are not.

have you tried on Nabble

http://old.nabble.com/forum/Search.jtp?forum=14201&local=y&query=header+only+library

Thanks for the pointer. I now slightly better understand the arguments from both sides. I am still inclined towards header-only approach, easier to upgrade to newer versions of boost and easier to manage project's build system without external dependencies. And boost's built binaries for windows/linux/mac (with 32 and 64 bit versions of on each, both release and debug variants) are >8GB. Not committing them in SVN means much higher setup cost when trying to reproduce older builds and otherwise it bloats the repository by that much after each boost upgrade (how do others manage this?). Just ranting out in case it influences future direction. SG