| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2005.06.03 08:18 "Re: vb port soon available", by <melser.anton@gmail.com>On 6/2/05, Edward Lam <edward@sidefx.com> wrote: > 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. Cheers Antoine -- G System, The Evolving GUniverse - http://www.g-system.at |
|||||||