-
2000.04.18 06:19 "Re: SGI tiff 3.5.5 make install error .....", by Jan Prikryl
-
2000.04.18 09:38 "Re: SGI tiff 3.5.5 make install error .....", by M. L. Welles
-
2000.04.18 14:42 "Re: SGI tiff 3.5.5 make install error .....", by Jan Prikryl
-
2000.04.18 18:00 "Re: SGI tiff 3.5.5 make install error .....", by Sam Leffler
-
2000.04.18 18:36 "Re: SGI tiff 3.5.5 make install error .....", by Chris Hanson
- 2000.04.18 18:51 "Re: SGI tiff 3.5.5 make install error .....", by Sam Leffler
- 2000.04.19 16:48 "Re: SGI tiff 3.5.5 make install error .....", by Roy Darrall
- 2000.04.19 06:20 "RE: autoconf based configure", by Kevin D. Quitt
-
2000.04.18 18:36 "Re: SGI tiff 3.5.5 make install error .....", by Chris Hanson
- 2000.04.18 19:29 "Re: SGI tiff 3.5.5 make install error .....", by Frank Warmerdam
-
2000.04.18 18:00 "Re: SGI tiff 3.5.5 make install error .....", by Sam Leffler
-
2000.04.18 14:42 "Re: SGI tiff 3.5.5 make install error .....", by Jan Prikryl
-
2000.04.18 09:38 "Re: SGI tiff 3.5.5 make install error .....", by M. L. Welles
2000.04.19 20:48 "LibTIFF portability, makefiles, install...", by Antonio E. Scuri
Related to the current discussion of the LibTIFF install I have many comments.
First I use my own makefiles/projects to compile LibTIFF in Windows/Linux/IRIX/AIX/Solaris and everything works fine even with updates of the library.
That's why I would like to say that I don't care much about autoconf files. But I had to do some stuff on the first time:
- port.h (new file)
- g3_states.c (new file created using mkg3states.c) (fax3sm_winnt.c)
- version.h (new file created using mkversion.c)
- tif_compress.c (to enable lzw compression, it is not illegal to include this in an open source library, it is a problem of the library user)
- tif_jpeg.c (#define boolean jpeg_boolean) before (#include "jpeglib.h") this a consequence of the include of the Windows.h in the LibTIFF main header, what I disagree.
After some years developing software that must be portable to many platforms we decided that it is much more simple to use an ANSI C code than to define lots of OS macros and specific files like "tif_win32.c".
In my opinion LibTIFF can have a base implementation without any dependency on the system where it is compiled (including header files). And of course can have some modules with optimized implementations like "tif_win32.c", for those who want it. In practice I see these optimizations as an enhancement to the Library than as part of it.
This approach eliminates most of the problems with the LibTIFF installation and build.
For example, the include of the Windows.h in the TIFFIO.H it is not necessary, it can be done only in the tif_win32.c. This is a very huge header that affects the compilation of other modules unnecessarily.
Also I wrote a port.h file that works in all the systems I build the library and it doesn't seem to be hard to eliminate the need of generating this file. The mkg3states.c also seems never to change, so the generated file can be always the same.
I think it is more appropriate to generate modules for special systems, than to try to generate a super configurable code for lots of systems. Based in the fact that you have an ANSI C compiler.
I also know that this suggestions demands many changes to the actual library code and it is much more complicated to change this code since it is very stable now, even with the compilation details. Anyway LibTIFF is a very important library and I think we can improve even more its source code quality.
Best Regards,
Antonio Scuri