
On Tue, Feb 2, 2010 at 9:34 PM, Vicente Botet Escriba
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