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