-------- Original-Nachricht --------
Datum: Mon, 21 Mar 2011 22:04:54 -0700 (PDT) Von: Artyom <artyomtnk@yahoo.com> An: boost@lists.boost.org Betreff: Re: [boost] [context review] Several Questions
could you please so kind to get my working tree?
git clone git://git.gitorious.org/boost-dev/boost-dev.git
It would help that we are using the same code basis.
Ok, I can take a look on this, but see notes below.
not necessary - thx
I'm not missing -fPIC option. -fPIC is used only for building shared object, you don't use it for executables!
I don't know why bjam adds it for executables. It is plane wrong (harmless but wrong). No other mature build systems like CMake or autotools does this.
In the real world users would not use bjam and would not compile their executables with -fPIC as it is not required.
it was too late last night - I'll take care of it this afternoon
I think it is better to build the examples with bjam. That means:
No, I should build libraries with bjam, but by no means, any code I write should be build with it. :-)
I thought bjam is the default for compiling boost libs? at least the docs tell it
I mean something like
boost::context<> // some default boost::ucontext<> boost::fcontext<>
You can always fall-back to ucontext if assembly version is not provided.
I think it would be very useful. Because different parts of program may required different contexts and inability to use two of them in same executable is quite problematic.
the problem is that it is unlikely that I can implement fcontext for all platforms and ucontext is not available for some platforms (for instance ARM - I know glibc-ports but you don't have always the possiblity to patch/recompile the C-lib). that means on some systems boost::ucontext<>/boost::fcontext<> may not be available. I've some doubt that this is acceptable. regards, Oliver -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone