"JOAQUIN LOPEZ MU?Z" wrote:
My machine is tied up at present: can you double check that moving codecvt_null.cpp to boost_wserialization breaks dll building of Serialization with msvc? (I'm 99% sure it will do if the header is included by any of the sources).
My results:
1. codecvt_null.cpp moved from SOURCES to WSOURCES. - MSVC++ 8.0: all tests pass - MinGW 3.4.5: narrow char tests pass (only tested a handful)
2. codecvt_null.cpp moved from SOURCES to WSOURCES, BOOST_ARCHIVE_DECL-->BOOST_WARCHIVE_DECL in codecvt_null.hpp, BOOST_ARCHIVE_SOURCE-->BOOST_WARCHIVE_SOURCE in codecvt_null.cpp (see attached diffs): - MSVC++ 8.0: all tests pass - MinGW 3.4.5: narrow char testspass (only tested a handful)
Why do you assume moving codecvt_null.cpp from SOURCES to WSOURCES would break MSVC tests? If your concern is related to the possibility that codecvt_null<wchar_t> member functions aren't properly exported, take into account that exportability is not controled by the library the .cpp is bundled into, but only by the macros BOOST_[W]ARCHIVE_DECL and BOOST_[W]ARCHIVE_SOURCE: having the narrow version or the wide version of the macros in place make no difference, the end result is that the member functions are imported/exported as they should. Of course if we switch codecvt_null.cpp from SOURCES to WSOURCES having the wide macros rather than the narrow is the aesthetically consistent choice, but it makes no difference from a practical point of view, AFAICS.
Hmm, as it stands: 1) When building the boost_serialization sources then the codecvt_null members are declared as exported, but aren't actually in the dll: in the past I've been hit by linker errors if you don't actually export everything you claim to, but strangely not in this case? 2) When building boost_wserialization sources other than codecvt_null.cpp then the codecvt_null are declared as imported, even though they are actually exported: that's normally a linker warning. I'm testing now with the macros changed to use the W variants... John.