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

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2007-04-04 13:43:35

On Monday 02 April 2007 17:41, Jeff Garland wrote:
> Sohail Somani wrote:
> > Its just not good practice and I suspect a non-empty subset of new
> > boost users are also new to C++.
>
> 5 years ago I believed it was a serious issue too -- I've substantially
> changed my mind.  And not in small part by using asio (and other boost
> libs) as header only.  It's extremely nice to not need to figure out how to
> build and link.  You can get started with so trivially with an all header
> library -- and I think that frequently it's trouble getting over that first
> hump that stops people from using libs.  So if the barrier is lower more
> people will use the libs.

I'd just like to second this aspect. I know that my first attempts at getting 
Boost.Thread to work were fruitless, because the behaviour and complexity of 
the build-system were so intimidating and frustrating that I simply gave up. 
I guess that many think so, at least I have had a lot of discussions that 
went into that direction on the Usenet.

Now, what I did here was to create an additional file that can be included 
as "boost/thread/inplace_link.cpp". All that this file does is #include the 
sourcefiles from lib/thread/src. Now, in order to use threads, all you need 
to do is to include this file into exactly one translation unit, that's it. 
Really, that is all! Apart from static linking, this has an additional 
advantage: ABI independence.

If you have a bunch of C++ compilers on your machine, you need just as many 
SOs/DLLs, which all have to be built. Using GCC, those don't even have 
different names, so there is no way to use different ones alongside. 
Considering STLport, it can at least be distinguished from the native one, 
but STLport 5.1 is not binary compatible with STLport 5.0, so the problems 
remain.

Note: I haven't tried it on MS Windows yet (only on vanilla Debian/Linux/x86), 
but I guess that due to the dllexport/dllimport stuff, you might have to set 
a switch so that static linking takes place, at least for the inplace-linked 
Boost libs. The reason is that otherwise the symbols get decorated with 
dllimport attributes which we don't want, since we are linking in place. I 
don't remember, what was the default link type there? If it is static, we are 
all set. Also, I used to call this 'inplace-link', but 'inplace-compile' 
would be more suitable.

Further, note that this does not replace the existing mechanisms for dynamic 
or static linking but enhances them. If you want, you can still use dynamic 
or static precompiled libs, but otherwise it significantly lowers the entry 
barrier by skipping any precompilation requirement.

Uli