another way to (not) build the libraries
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. 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. Well, at least we thought so, some files moved between Boost versions inside the source folder, 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. Anyhow, what I wonder is whether this is not a way that should be supported actively. In our case, it significantly reduced the adoption barrier for the threading lib, it also makes bjam use unnecessary (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 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). 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. cheers Uli [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. #include <iostream> #include <ostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> // for 'static' linking #include <libs/thread/src/thread.cpp> #include <libs/thread/src/xtime.cpp> #include <libs/thread/src/mutex.cpp> #include <libs/thread/src/exceptions.cpp> #include <libs/thread/src/condition.cpp> void thread() { std::cout << "thread(): entering\n"; boost::xtime tm; boost::xtime_get(&tm, boost::TIME_UTC); tm.sec += 2; boost::thread::sleep(tm); std::cout << "thread(): leaving\n"; } int main() { std::cout << "main(): creating thread\n"; boost::thread th(&thread); std::cout << "main(): waiting\n"; th.join(); std::cout << "main(): done\n"; }
"Ulrich Eckhardt" wrote:
Later on, we replaced that with #including the sourcefiles (<lib/thread/src/...>) into a single file
I too use this way and prefere it very much to bjam. I met few problems: older Serialization (around 1.32) had issues in mixing binary and text archive files together.
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.
Perhaps this may start as page on Boost.Wiki and if enough of information is collected it may its way into documentation. /Pavel
Ulrich Eckhardt <doomster <at> knuut.de> writes:
Anyhow, what I wonder is whether this is not a way that should be supported actively. In our case, it significantly reduced the adoption barrier for the threading lib, it also makes bjam use unnecessary
I'd be very keen to seen this form of usage documented
Really useful message, not drawn in the sea! I have a similiar question, maybe just because I set something wrong, now I compiling some code in vc++ 2005 express, I found a very strange linking problem, it failed to find the class member unless I put those function bodies into the header file(just copy & paste or include .cpp file at the end of the header file). It seems really stupid, and I wonder why it happens! I am not sure if it is my own mistake because it is my first time using the vc++ 2005 express. I need to use boost and some other odbc libraries for windows applications, any other solutions? Thanks in advance! On 3/29/06, Ulrich Eckhardt <doomster@knuut.de> wrote:
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. 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. Well, at least we thought so, some files moved between Boost versions inside the source folder, 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.
Anyhow, what I wonder is whether this is not a way that should be supported actively. In our case, it significantly reduced the adoption barrier for the threading lib, it also makes bjam use unnecessary (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 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).
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.
cheers
Uli
[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.
#include <iostream> #include <ostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp>
// for 'static' linking #include <libs/thread/src/thread.cpp> #include <libs/thread/src/xtime.cpp> #include <libs/thread/src/mutex.cpp> #include <libs/thread/src/exceptions.cpp> #include <libs/thread/src/condition.cpp>
void thread() { std::cout << "thread(): entering\n";
boost::xtime tm; boost::xtime_get(&tm, boost::TIME_UTC); tm.sec += 2; boost::thread::sleep(tm);
std::cout << "thread(): leaving\n"; }
int main() { std::cout << "main(): creating thread\n"; boost::thread th(&thread); std::cout << "main(): waiting\n"; th.join(); std::cout << "main(): done\n"; }
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- bwlee
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
On 3/29/06, Ulrich Eckhardt <doomster@knuut.de> wrote:
different compiler versions or settings 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).
Doesn't the linker include only those parts of a (static) lib that are actually used?
At 5:13 PM +0200 3/29/06, Olaf van der Spek wrote:
On 3/29/06, Ulrich Eckhardt <doomster@knuut.de> wrote:
different compiler versions or settings 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).
Doesn't the linker include only those parts of a (static) lib that are actually used?
Depends on the linker. Dumb linkers include everything - because it is simpler. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Marshall Clow <marshall@idio.com> writes:
At 5:13 PM +0200 3/29/06, Olaf van der Spek wrote:
On 3/29/06, Ulrich Eckhardt <doomster@knuut.de> wrote:
different compiler versions or settings 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).
Doesn't the linker include only those parts of a (static) lib that are actually used?
Depends on the linker. Dumb linkers include everything - because it is simpler.
For G++ to do that you might need to compile with -ffunction-sections -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (7)
-
bwlee -
David Abrahams -
Marshall Clow -
Olaf van der Spek -
Pavel Vozenilek -
Simon Carter -
Ulrich Eckhardt