----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Sohail Somani Sent: 03 April 2007 22:22 To: boost@lists.boost.org Subject: Re: [boost] [system] Why is this not header-only?
[mailto:boost-bounces@lists.boost.org] 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: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com