Ulrich Eckhardt <doomster@knuut.de> 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