2000.04.17 19:03 "SGI tiff 3.5.5 make install error .....", by Hezekiah Mcmurray

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:

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