This discussion reveals why I haven't addressed the issue yet. Here is my analysis. There are two different situations: a) A DLL which contains the same code as the libboost_serialization.lib and libboost_wserialization.dll . I see this a no problem and just a question of making the changes required to implement AUTOLIB in accordance with the instructions on the boost website. This would work exactly as the current system and have no repercussions that I know of. b) A dll that contains serialization functions related to a users classes. This is an entirely different situation than that of a) above. This has several aspects: i) If the DLL containing serialization for a given class X is loaded at the beginning of program operation and not unloaded until program termination there should be no problem. ii) if the DLL is loaded and unloaded dynamically, it will not currently work without changes to the library. The changes are doable but perhaps a little intricate. iii) if code for the same class is included in multiple DLL's there could also be problems. These are probably addressable with the changes referred to in ii) above. My view is that this situation would cause problems in areas other than serialization. Neal's original example which started this discussion is a case in point. The concept of having the same code in different DLLS seems to raise questions about undefined behavior. Adding things like static class variables makes it even more ambiguous in my mind. This is an area ripe with un-intended consequences. So my strategy has been to: a) add no functionality pending release of 1.32. Of course if I had known that branching would be 3 months after the originally scheduled time, I might have continued adding functionality a little longer. My main motivation is that this library (as well as other boost libraries) have to have reliability as absolutely number one priority. b) release 1.32 c) add AUTOLIB support and test with DLL versions of libboost_?serialization.dll d) augment code to permit dynamic loading/unloading of DLLS which include class serialization code. Intricate to code, very hard to test on multiple platforms - especially when one doesn't have these platforms available locally. e) augment manual to describe the pitfalls of including the same code in separate DLLS and promote the idea that source code and build should be organized to prevent this from happening. Of course anyone is free to tweak there own copy and get ahead of me on this. But I believe that considerations of portability and robustness require me to move at a more deliberate pace. Robert Ramey "Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:cl32n6$ss4$1@sea.gmane.org...
Russell Hind wrote:
I have successfully built serialization as dlls under bcc32 by duplicating the two 'lib' sections in the JamFile and renaming them to dll and then adding the <dll>libboost_serialization and <dll>libboost_wserialization to the install and stage sections.
Could this be done in the JamFile before 1.32.0 is released?
Thanks
Russell
Russell Hind wrote:
So will serialization build dlls by default when 1.32 ships? I've just started to build it with bcc32 and currently use auto-link which forces everything to be a dll (due to thread requiring to be a dll on win32 in 1.31).
The issue is not whether you can build dll, but whether it will actually work correctly.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost