[Proj] Coming releases of PROJ.4

[Even Rouault]

Kristian,

> The projects.h interface has a long history and exposes
> most of the inner workings of PROJ.4. 

As far as I know in the FOSS ecosystem, projects.h use is very marginal, or accidental. The 
only occurence I've in mind is in the OGDI project that uses nad_init() in one place. But I 
wouldn't mind too much about OGDI...

> That is also why the
> proj_api.h interface exists. It was created in an effort of simplifying
> things and making a more modern API. That was now roughly 15 years ago, and
> On top of that it has some unfortunate
> design choices, for instance the context-system which is rather hard to
> work with and comprehend. Unfortunately it is also completely undocumented
> and the original ideas behind it seem to be lost.

I'm not completely sure but I think the main driver for the context system was to remove / 
deprecate use of pj_errno as a global error variable. errno is now attached to the context.

While just reviewing proj.h, I had a few questions/observations :
https://github.com/OSGeo/proj.4/issues/529  (I see you've began to answer to some 
questions while I was still editing it ;-))
We should probably make sure it is in a clean enough way before releasing it to the world

> 
> PROJ.4 also has three different build-systems: Autotools, nmake and CMake.
> Autotools is the authoritative build-system which the other two try to
> mimic as best as possible. Nmake was introduced in order to build PROJ.4 on
> Windows and lately CMake has also been introduced as there was a demand for
> it.
> 
> Due to the above I suggest that we focus our efforts entirely on the proj.h
> API and CMake from the next release and onwards.

Adoption of the new API and deprecation of proj_api.h will show greater resistance than 
dropping autoconf/nmake.

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.

In the transition period, proj_api.h could have two sections : a section with the new API and 
with the ancient API clearly separated. At some point ancient API would be removed.

On the other hand, having the new header and removing the old one will be an obvious way 
of signaling "eh, breaking changes have occured !" :-) 

Actually one of the point of having a dedicatd proj.h would be to make sure that people don't 
accidentally use old API that will be removed. But I see that proj.h includes proj_api.h, so this 
risk still exists.  Why proj.h couldn't avoid the proj_api.h depedency ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170622/41f592e2/attachment.htm