2005.06.02 20:50 "[Tiff] vb port soon available", by Antoine

2005.06.03 08:18 "Re: [Tiff] vb port soon available", by Antoine

I think that a better approach would have been to add something like TIFF_EXPORT in front of all the functions that we need to export. And then we can just have some options to control this #define in config.h.

On Windows for example, one can use this to do away with the need for a .def file by doing:

#define TIFF_EXPORT __declspec(dllexport)

This would allow everything to go into one baseline. I detect multiple baselines because what happens if a bug gets fixed in only 1 of them?

This would clearly be better, but I assumed that as it hadn't already been done then there was a reason why not. Maybe not. I would think that we should keep the .def file (seems nicer to keep the exports in one place), but maybe have a flag on the compile line that if provided, would define __stdcall for the appropriate functions. If you think this would be ok then I could have a go at it. I can take some inspiration from what is there.

I clearly thought that there was no interest in VB (and had no idea why it didn't "just work"), if the contributors are OK to start having a bit more doze specific stuff in conditional defines then great, I'd be over the moon for it to go into the std distro... that means I don't have to redo it for every release! If not, then I'll keep plugging along and get the sourceforge site up and running. I am also going to be working on an activex that will encapsulate some libtiff functionality, but will also use freeimage (freeimage doesn't give you much freedom with your tiff options) - that is probably not so good for contrib.


G System, The Evolving GUniverse - http://www.g-system.at