Boost logo

Boost :

From: Martin Bonner (Martin.Bonner_at_[hidden])
Date: 2007-04-04 04:54:04

----Original Message----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Sohail Somani Sent:
03 April 2007 22:22 To: boost_at_[hidden]
Subject: Re: [boost] [system] Why is this not header-only?

>> [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.

I don't know if you're the ONLY one, but I would have to be pretty
pushed to touch the internals of a library (as in, if there's an easily
patchable bug, I would prefer to work around it until the next release).

If shared_ptr had not been header only, I am pretty sure I could not
have got it in use in my company. There is a BIG difference between
"I've added a header tree to the 'install' folder in Source Control",
and "you need to install this chunky library on your system in order to
be able to develop this project".

Martin Bonner
Project Leader
Telephone: +44 1223 441434 / 203894 (direct)
Fax: +44 1223 203999
Email: martin.bonner_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at