LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2000
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2000.04.18 19:29 "Re: SGI tiff 3.5.5 make install error .....", by Frank Warmerdam
Jan Prikryl wrote: > > Quoting M. L. Welles (mike@onshore.com): > > > If someone does come up with a fix for this, I'd like to apply it to the > > CVS source quickly. > > > > Otherwise, if anyone could donate shell access to an SGI Irix box that > > we could use for testing builds (or at least quickly fixing this > > problem), we'd greatly appreciate it. > > Here is the patch ... tested on Irix 6.5. Shall be appiled in the root > directory of libtiff with > > patch -p0 < tiff-makefile.patch > > By the way, the install part of current makefiles seems to be > SGI-specific (at least it relies on SGI-specific /sbin/install). It > will probably not work on many architectures (it sure does not work on > my Linux). It could pay off to switch libtiff to automake/autoconf, > has anyone done anything in this direction already? Jan, I have applied your patch, and verified that it makes things work on the SGI I have access to. I am supportive of switching to a autoconf/automake/libtool based install; however, I am worried there will be some degradation on some platforms. For instance, the loss of the SGI specific install logic. I also dislike using libtool in packages I am doing active development, but I think I can learn to deal with it. I have recently deployed PROJ.4 using autoconf/automake/libtool and that worked reasonably well. If there aren't too many objections, perhaps Mike and I can look at switching libtiff over the next few months. In deference to Chris Hanson's objection, I agree that it is desirable to retain the current organization of source, and perhaps to distribute a dead simple non-configure based Makefile for the libtiff and tools directories. This could be easily hacked for "problem" platforms. Also, NMAKE and other build mechanisms for non-Unix platforms can be retained. My main concern is that a shift to a new configuration mechanism will cause hassles for a while. Files that get forgotten, DSO support that might be lost of some platforms. However, it might make it practical to make libtiff configuration "smarter" about stuff like using libjpeg, libz and other stuff if available on the system. Best regards, ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerda@home.com light and sound - activate the windows | http://members.home.com/warmerda and watch the world go round - Rush | Geospatial Programmer for Rent