John Maddock wrote:
I believe that both issues should be solvable with header refactoring: as far as auto-linking goes, it means that the declarations for objects that are placed in the compiled lib need to be factored out into separate headers.
This is basically the problem. header extended_type_info can be included in places where not all the functions are in fact called. So normally there would be no need to link the library. OTOH, just including the header provokes the auto-linking. I'm currently looking at how to factor this into two pieces - one that is header only and one that requires linking to a library. This is made somewhat more tricky that first meets the eye due to the fact the the serialization library is pretty large and that extended_type_info in used in several places for similar but unrelated purposes.
Robert: is there any help you need from me with the auto-linking code? Anything that you don't understand or is causing problems here?
In the course of implementing auto-linking in the serialization library I became quite familiar with the auto-linking facility - much more than I thought I would have to be. In large part this is due to the design of the serialization libary. Its actually three pieces a) basic faciliies - e.g. extended type info, void_cast, etc b) basic archive facilities - serialization.lib (which includes a) above) b) archive faciltiy for wide char i/o - wserialization.lib. This latter imports references from b) above since that library/DLL contains the archive base class implementations. So it was quite an effort to keep these things from stepping all over each other. The final result is quite clean and I only have this problem left which I am working on now. Robert Ramey