2004.09.15 15:02 "Re: [Tiff] Calltype support", by Bob Friesenhahn
This works perfectly, but has a great disadvantage: Migrating to a new version of the LibTiff is painful because we have to do the same work again.
Have you ever thought about adding calltype support, like the JPEGlib does? I think the readability of the code does not decrease. Or are there other (better?) ways to add calltype support?
I would agree that wrapping all the public definitions in appropriate macros is desirable and I do this on various other projects. Please submit a bug with the request.
However, isn't there a way to direct the compiler to use a particular calling convention that would avoid all this?
The only other means available appears to be to maintain a separate ".def" file to tell the linker which functions should be exported. This is very easy to implement but it adds another file to the build. I think that the user of the header files still needs to know which functions are imported from a DLL so that they use the right calling convention. This is painful for the library user.
I notice that for GraphicsMagick we have hacked our libtiff headers to declare functions like:
extern TIFFEXPORT tsize_t TIFFReadTile(TIFF*,
tdata_t, uint32, uint32, uint32, tsample_t);
so that explicitly exporting functions is possible.
I therefore support adding the hooks to export functions under Windows, but don't think that obfuscating all function declaractions with macros is a necessary approach.