2. The CriticalSection instance in log4cxx::helpers::ObjectImpl causes config.h to be expanded for the abstract classes in public API. Isolating implementation details from the client API would require removing the CriticalSection from the abstract base class and reintroducing it in the concrete implementation classes. perhaps via templating and/or macros.
Another solution is to typedef the main types we use in threading, depending on PTHREAD (not HAVE_PTHREAD), and WIN32. This will require the library user to add -DPTHREAD on it's compiler command line, which is not a problem I think (a lot of other library do).
For example in portability.h, having:
The mechanism used for critical sections is an implementation detail that is ideally invisible to the client application. I think it is much more preferable to hide that implementation detail than to make the build for the client application guess the value used to build the library.
