Re: [boost] [system] Why is this not header-only?

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-04-03 17:21:35

> [mailto:boost-bounces_at_[hidden]] On Behalf Of Jeff Garland
> 
> Sohail Somani wrote:
> 
> > Oh come on guys, aren't we just getting silly? To avoid 
> what? Adding cpp
> > files to the build?
> 
> Yeah, actually.  Here's a response to your earlier mail:

Sorry I must have missed it.

> Sohail Somani wrote:
> 
>  >> This is a non-issue. With header-only libraries, step 1 is
>  >> the only thing that disappears and you might even be lucky
>  >> enough to disable language extensions in your project.
> 
> I assure you, given the number of posts on this list and the 
> -user list, 
> building boost is something people have issues with.  I've 
> had to answer the 
> 'link errors' question many times for date-time -- even 
> though this is basic 
> knowledge that all developers should have, and it's "all in the docs".

I'm going to say that people have problems building boost with bjam
unless you can prove otherwise. In my opinion, bjam is the blocker. Not
the fact that you have to build some files. Boost.Config is the key to
making it easy.

>  > Actually, step 1 is replaced with "try build with bjam, 
> send emails to
>  > the mailing list"

> Right, and best case, you're into an hour or two of fiddling 
> around that had 
> nothing to do with what you were trying to accomplish -- 
> which is simply to 
> read the docs and use the library.  And while I understand 
> the sentiment the 
> C++ programmers have been dealing with this for years, etc, 
> etc.. it's still 
> really nice when getting started with a new lib that the 
> barrier to entry is 
> more like a scripting language than traditional C/C++ libs.

Agreed. I don't see why "add boost/libs/<lib>/src/*.cpp to your 'visual
studio project'" is harder than export
PYTHONPATH=/path/to/my/fancy/new/lib:$PYTHONPATH. Indeed, on Windows,
this is even more annoying.

If the policy is: *Don't* depend on bjam for your build, and I've found
most separately compiled Boost libraries *don't* do this, then add
src/*.cpp to your build is the better solution.

Am I the only one on this list who thinks this way (or is willing to
speak up about it)? I've seen developers refuse to work on a library
until they've factored it into appropriate separately compiled units.

Sohail