Re: [boost] another way to (not) build the libraries

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-29 09:15:50

Ulrich Eckhardt <doomster_at_[hidden]> writes:

> Greetings!
>
> I think it was with boost 1.30 where we started using the threads library and 
> at that time build support was not yet at the stage where we could really use 
> it the way we wanted it to so we mostly invented our own. The first thing we 
> did was to copy the required sourcefiles into the project where we needed 
> them, i.e. the most primitive form of static linking. 

Call this approach A.

> Later on, we replaced 
> that with #including the sourcefiles (<lib/thread/src/...>) into a single 
> file - the same thing only done in a way that we could switch to the next 
> Boost version without changing our code. 

Call this approach B.

Why would approach A require you to change your code when switching to
the next Boost version?  And what possible advantage does approach B
have over approach A?  I can certainly imagine that approach B will
break if some of the implementation files begin using unnamed
namespaces.

> Well, at least we thought so, some files moved between Boost
> versions inside the source folder, 

That's just one of the problems with approach B.

> another problem is that e.g. timeconv.inl provides things in an
> anonymous namespace and gets included by more than one sourcefile
> but doesn't have include guards.

Even with #include guards, two source files could define the same name
in an unnamed namespace.

> Anyhow, what I wonder is whether this is not a way that should be supported 
> actively. 

Why?

> In our case, it significantly reduced the adoption barrier for the 
> threading lib, it also makes bjam use unnecessary

Whether you use approach A or B or you write your own makefiles, bjam
is never necessary, provided you're willing to duplicate the work of
figuring out everything needed on the command-line to do the build
correctly.  

> (which I, even though I did quite some things with it already, still
> find unwieldy and don't completely understand), it avoids the
> problem of different compiler ABIs due to different compiler
> versions or settings 

So does either of these:

  1. Windows auto-linking

  2. Regardless of platform, using Boost.Build to build your own
     project as well as the Boost libraries.

> and it reduces the additional required size of the final executable
> (example-prog[1] with above static linking weighs 52kB, the thread
> lib alone would have been 92kB already otherwise).

?? if you link to the static thread library, don't the unused parts of
those 92kB get linked away automatically?

> I personally would be interested in documenting how to use Boost
> libs this way and also make it an officially supported way to do so.

Nothing Boost can do will ever make building in this way as foolproof
as it can be with Boost.Build, and IMO it needlessly restricts library
implementations.

> [1]: The example program below has been compiled with GCC using Boost 1.33, 
> the only patch necessary was to add include guards to timeconv.inl.

I have no problem with the idea of adding include guards to timeconv.inl.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com