[Proj] Coming releases of PROJ.4

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> I'm wondering: is there a reason for having a new proj.h ? (we perhaps discussed that, but I 
> already forgot) Imagine that I want to write code that is compatible of old and new proj 
> versions (I'm pretty sure that a number of proj users will have to do that at some point). It 
> could be convenient to still include proj_api.h and depending on the value of PJ_VERSION 
> decide which API are available. Whereas if you have a new header, that make you also change 
> your autoconf/cmake logic detection of proj4.

Really, all proj-using programs have to be able to cope with both old
and new.   Whatever packaging system exists will have either old or new,
and then some other program will either work smoothly in both cases or
be a source of trouble for the packagers and maybe get dropped.

If that doesn't work, then the only other sane alternative is to have a
completely new namespace so that proj4 and say proj5 can be installed in
parallel and have no conflicting names.  But from the packging POV, I
see that as very much non-preferred, and an approach for when normal
compatibility doesn't work.

All that said, a new header for a new API does not sound bad, if
programs are expected to detect whcih and have ifdef, at least for now.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20170623/58ecea0d/attachment.pgp