About this, I have a problem with some ac variables you use in log4cxx.h.in
but which are not set by configure.in :
LOGCHAR_IS_UTF8 and HAS_WCHAR_T
How do you expect them to be defined ? Do I add some option to configure of do
I compute it from --enable-unicode ?
Sorry, I forgot about that. LOG4CXX_HAS_WCHAR_T should be detected. It indicates whether or not the compiler has a wchar_t type. If it doesn't then, then all the API methods involving wchar_t would disappear.
LOG4CXX_LOGCHAR_IS_UTF8 indicates that LogString (the internal string type) is a std::string encoded in UTF-8. Currently either LOG4CXX_LOGCHAR_IS_UTF8 or LOG4CXX_LOGCHAR_IS_WCHAR is 1 and the other 0. It is possible, but unlikely, that at some future date that other options for LogString would be provided.
Obviously if the compiler doesn't have a wchar_t then LOG4CXX_LOGCHAR_IS_WCHAR should be 0. LOG4CXX_LOGCHAR_IS_UTF8 = 1 is likely the better value for the Unix's and LOG4CXX_LOGCHAR_IS_WCHAR = 1 for Windows. If you knew at compile time the locale charset would be UTF-8, a lot of the character encoding and decoding could be short-circuited to memcpy's.
I think you should add some option to configure. Either option should support "unicode" except on a few platforms where wchar_t is a little weird, so --enable-unicode doesn't seem to fit. On those few weird platforms LOG4CXX_LOGCHAR_IS_WCHAR = 1 should not be used since log4cxx expects that you can represent any string as std::basic_string<logchar> and it can be converted to a UCS-4 scalar value.
Changing the logchar totally breaks any binary compatibility, so it should be very rare to change it to something other than the platform default. Probably should just leave it as LOGCHAR_IS_UTF 1 in the log4cxx.h.in and if you really want to change it, you can use the Ant build or we can add the option later.
