2008.12.18 18:59 "Re: [Tiff] tiffvers.h - TIFFLIB_RELEASE macro addition", by Frank Warmerdam

The available values are CURRENT, REVISION, and AGE in order of decreasing significance. For example, CURRENT might be 4.

But this is not normally conveniently available to applications building against libtiff, right? It requires some sort of configure magic to extract the libtool versioning and represent it as macros passed into the application. It wouldn't do anything for someone on windows for instance.

Right. That is where the substitution magic which builds tiffvers.h comes in. Then the versioning info is available to all. It is not difficult for configure/make to maintain a continually up to date tiffvers.h.

The approach you describe still only works if the major release update always offers additional features over the previous major release.

I do not understand this comment.

What I mean is your use of arbitrary libtiff version numbers to determine if a feature is available. Features can be backported and it is even possible that a lesser numbered library supports a feature which is not available in a higher numbered library.

Folks,

OK, I'm finding interest in TIFFLIB_RELEASE lukewarm at best, and I have decided against going ahead with it. I'll leave things as they are in this regard. For my own purposes I already need to detect whether I have BigTIFF support, so I'll just use TIFFUnsetField() if the date is later than a particular date, and if I have bigtiff support.

Best regards,
--
---------------------------------------+--------------------------------------

I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam

and watch the world go round - Rush    | Geospatial Programmer for Rent