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

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
PI SHURLOK LTD
Telephone: [phone] / 203894 (direct)
Fax: [phone]
Email: martin.bonner_at_[hidden]
www.pi-shurlok.com