> I guess a good compromise would be to build win_iconv also into a DLL > with the same name and same ABI and API as the GNU libiconv > iconv.dl... Then a packager can choose which iconv.dll to include. The > preferred way to use win_iconv would still be to just build it > statically into whichever DLL or EXE that needs it, but the DLL could > also be used as a drop-in replacement for the GNU iconv.dll.
Sorry for the delay. I think that is a quite good idea. Statically built packages won't care about iconv.dll and dynamic ones can be fed with either GNU iconv or win_iconv, whichever the user prefers. It is also comfortable from the packaging point, for me. I have iconv as a separate package and adding a win_iconv won't hurt anyone. Users must deploy a package anyway, they would then just be able to choose one of the two. Most Windows users would not make a mistake in choosing either, because most of them only ever use the encodings which their machine supports anyway. I guess this is a good option. Ciao, Igor _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
