>> I still don't get what the problem is with this. You decide what >> you build your application with, and things will just work for the users >> because the runtime package contains all the necessary files to run the >> application, regardless whether you build against the MSVCRT80 or the >> MSVCRT90 runtime.
Sure, but some people will build from source. For them, I need to provide a means of selecting the libraries to link against. No, it's not a particularly difficult technical issue, but it is an issue. >> But if there are two applications, one built with MSVC 2005 and one with >> MSVC 2008, then they should use different DLLs, right? If these DLLs >> have the same name, then this cannot work (at least not if the DLLs are >> meant to be shared). It can work if you install to different directories and set your path as needed. If, however, you require that multiple versions of the *mms coexist in the same directory, then your approach is reasonable. But now, the more I think about it, the less I like path-based discrimination of libraries. >> We used the same conventions as the boost C++ libraries, here: >> http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming Very persuasive that you're following boost conventions. I think I'm convinced. Phil
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
