In article
I see that several boost libraries can be compiled as dll files. I'd like to know if there's any concern about binary compatilibity between different versions of those dll's as boost's version number (and possibly the library itself) changes. For instance, whenever MFC's dll binary interface changes, we have another library version written in it's name (MFC42.dll, MFC70.dll, MFC71.dll...), this way we can help avoiding "dll hell".
Yes there is a concern with binary compatability from version to version. Because of the nature of C++ and Boost different versions of the code have no real hope of compatability :-( We've discussed in some of the Boost devel lists about such problems. And we are trying to address them. To make things more interesting it's not just a matter of having version numbers, but also what the compiler was, and some indication of what compiler features got used to compile the code. I have some changes to the build system which already does most of what's needed so if you are desperate for a fix try getting these files from CVS: http://tinyurl.com/hx8p and http://tinyurl.com/hx9i
It would be also cool to link a version resource in each dll. This way, installers would check if a newer dll exists in the system, avoiding overwriting with an older one.
Now that's a harder proposition :-) Unlike Unix where it's easy to add the equivalent with a single command line argument to the compiler. It's hard to generate that version resource and compile/link with the various tools that do and don't come with compilers. Of course if someone knows of a way to put such resources directly into a C source file, I'd love to know ;-)
And one last thing... the import library of date_time's dll isn't being generated, making it unusable. It's better to delete the dll target of its jamfile.
The files I point to above have that part commented out in fact :-)
If any help of my part is needed, I'd be glad to help.
In that case, definately try out the alternate build files and tell me what you think. But I would suggest subscribing to the Boost.Build(jamboost) list, see http://www.boost.org/more/mailing_lists.htm if you want to get more involved in build issues. -- -- grafik -- Don't Assume Anything