[Threads-devel] platform separation of code

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-04-10 19:01:58

I have just uploaded my first attempt to reorganize the threading code 
into platform dependent sections, to the vault.

Anthony, Matt, Please have a view on this before I will check anything 
into the CVS, since I need to reorganize the directory structure a bit. 
  I'd like to reach consensus on this before, because it is not easy to 
delete directories from CVS again once created.

You just can grab the boost_threadpp.tar.gz file and extract it onto 
your regular boost tree. It will not overwrite anything, since the new 
parts live in:
boost/threadpp
and
libs/threadpp
side by side to the current library. I am not sure if I should change 
the name back to thread again before going into the CVS. Your thoughts?

The platform split is made of two parts:

1) a include dispatcher macro within detail/platform.hpp which 
dispatches from user interface include files e.g. thread.hpp to 
win32/thread.hpp

2) a Jamfile which is able to build sources in a platform (and toolset) 
dependent way. (I am making use of the <build>no prerequisite.) 
Currently there is only a v1 file available, v2 to follow soon.

It is also possible to have some shared code, although I currently split 
everything.

The build is always attempting to compile for the pthreads interface 
where available (also on windows). Platforms known not to support 
pthreads can be (and should be) deactivated in the Jamfile, so no 
spurious errors are emitted.
This library is named boost_threadpp_pthread.
(This is the default on unix*.)

Then the Boost.build attempts a native build on platforms where native 
code is available. Currently this is true only for windows. Al tough I 
am not sure if it will make sense to create a native lib on linux too, 
this would be possible. (As well as for any other platforms.)
On windows this library is named boost_threadpp_win32.

The users later can decide at link time of his application which variant 
to use, i.e. pthread or native.

I rearranged enough of the code to demonstrate the principle, i.e. 
condition, mutex and thread.

What I know is missing:
autolinking,
tss,
barrier,
rwmutex,
Jamfile.v2,
tests,
dynamic linking

Also please note that I have not yet tried to link any userland code to 
the built libraries. I have tested however that the install command of 
bjam copies everything to the expected places, i.e. headers and all 
library variants.

Please let me know what you think about this setup, so I can adapt it 
further before going to CVS and writing more detailed developer 
documentation to the wiki.

Regards,

Roland