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

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-04 14:36:13

Hello Sohail,

Wednesday, April 4, 2007, 2:58:33 AM, you wrote:

> Well I was talking about getting the samples running which I thought is
> the biggest barrier to using Boost. But I was assuming that eventually
> the user would be happy enough to then compile it into a library
> themselves or figure out the magic of bjam.

But don't we need to compile Boost first in order to run examples?
IMO, we're walking circles here.

> The thing is, I've had these issues so many times (3rd-party libraries)
> that my build can basically handle any weird build requirements. So for
> me, building a new library is easy-peasy. I feel I will be getting
> punished because I solved the problem in a somewhat non-stupid way. I
> can't imagine any C++ developer not having solved this problem for
> themselves. Indeed the boost guys did by writing Boost Jam.

You see, I, as a library single user, would like to "plug'n'play" the
lib, not putting any effort in the building process. Sure, in
industrial-sized development world the building process is settled
this or that way, but still someone has to put a lot effort in it.

>> Externally linked modules (.dll or .so) often give a lot of headache,
>> though sometimes they are really needed. The most common problems are:
>> 
>> - The dll needs to be built first. That means I have to go read the
>> docs how to do it, what it depends on and compile.

> Ok, and? You have to do this with everything you use. If you start
> shipping "header-only" libraries, then you're just delaying the problem
> because you ship all the "libraries". The equivalent would be to compile
> all boost libraries into one giant dll. If you start shipping libraries
> separately (i.e. out of sequence releases - which is in the plan, I
> believe), the problem reappears.

I think, you got me a bit wrong here. I only noted that one has to put
effort to build the lib instead of just using it on spot.

In regard of boost releases separation, I don't quite see how
header-onlyness is connected to this. The library is a library, wether
or not it is header-only. We might separately ship Boost.Any, for
example. The only thing we have to do is to define libs it depends on
and their least versions that are required for the specific library
release.

>> - Not all compilers have auto-link feature (GCC, doesn't, BTW). So I
>> have to modify my projects to link against it. Note that this also
>> implies that the import .lib or .so has to be available during this
>> process. This may be easy to guarantee in small local builds but gives
>> additional problems when running large distributed and parallel
>> automatic (nightly) builds.

> Use a build system that can handle it. This is C++ after all.

See my previous arguments about "plug'n'play". In commercial
development it's time=money, in a personal builds it's just time and
effort.

[snip]

>> - There may be problems with some core C++ features like RTTI and
>> exceptions when used across dll boundaries. Linux is more affected to
>> this. I guess, this may also take place when compiled by different
>> compatible compilers modules interact (i.e. different versions of the
>> same compiler or compatible compilers like VC and ICL)

> I'll have to say that the best C++ interface is a C interface. Unless
> you ship your source. Which boost does. \o/

<sigh> I was hoping C++ libs could have C++ interface.

Actually the problem is present regardless of the source availability.

>> - There are various problems related to dll load/unload order and
>> dependencies between them.

> You'll have to specify where this is an issue with boost.

I wasn't speaking about specifically boost here.

[snip]

The bottom line. I agree that these problems have solutions. But in
a header-only case they wouldn't have even exist in the first place.

I must also say I agree that many libraries _should_ be dll (just
imagine something like xerces or ICU header-only... boo) but mostly
these are large and heavy libs. Small libs (like singleton) and
various wrapper-style libs (e.g. thread, asio) should have a
header-only option, if possible. And since we have different opinions
here, the user-defined configuration is the best choice, IMHO.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]