GNU Common C++ "2" 1.1, GNU pth, and NGPT

[David Sugar]

While there are a number of smaller issues that need to be resolved and 
finalized for a 1.1 release, including if the ccssl library will be part 
of it, if Dan's threadsafe streaming will be integrated fully, etc, there 
is one issue until now that has been left unaddressed, the question of how 
we should handle GNU pth and the NGPT thread libraries...

My thought on this is that GNU pth should be an alternate compilable 
build.  Normally one builds ccgnu2 which everything then is linked to.  In 
this scenario, an alternate ccpth2 would be created, and everything could 
alternately be linked to that.  This would allow one to have a choice of 
threading environment and characteristics (native, or portable) and to 
make that choice by which one is chosen at link time.

With the newer versions of autoconfig and automake it is possible to have
one set of sources build two or more different sets of objects since the
.o files are uniquely named by target.  However, this is not possible with
older and more common releases of automake and autoconf, however.  Hence
my proposal is to have a seperate pth subdirectory (along with src and
win32), and have the pth subdirectory build a ccpth library, often out of
the same source files as were used for ccgnu2, but with a CCXX_PTH
defined.  Assuming the base classes offer no alignment variances (and this
will be done through the headers), ccext2 and other things should then be
linkable against either ccgnu2 or ccpth2, and an option could be added to
ccgnu2-config to request linkage and compile time options for ccpth rather
than for ccgnu.

The curious question is what happens with platforms that have no native 
thread support at all, but do have a port of pth.  Should pth then become 
the ccgnu2 on those platforms?