[Proj] Coming releases of PROJ.4

[Howard Butler]

> On Jun 22, 2017, at 3:57 PM, Kristian Evers <kreve at sdfe.dk> wrote:
>  
> > Ditching manually-constructed and out-of-date nmake for cmake seems fine to me (ooh, CMake gives me project files now!), but ditching autotools that has worked for people for decades does not. That change would ripple into packagers and the distros for little or no appreciable benefit. 
>  
> I won’t claim to be an expert  in CMake, quite the opposite really, but I was under the impression that it  would be possible to set up CMake in a way so that it mimics the autotools behavior exactly when UNIX makefiles are generated. I am completely wrong here?
> The benefit would be to limit the amount of code we have to maintain. It would only benefit us, true, but it would also free time that can be spend improving the overall project instead of maintaining status quo. I don’t feel too strongly about this, I just wanted to throw it out there while I was at it.

CMake can produce a somewhat passable facsimile to autotools behavior, but there are many nuances and autotools features that CMake doesn't support or support in the same way. These things matter to the distribution packagers and maintainers, and I've found it's often more trouble to make CMake behave the way they need than it is to just provide an autotools layout implementation. That situation in 2017 is better than it was in 2008 when I started using CMake, but it is still a friction point.

> > but I must say I'm very skeptical that we can actually *remove* anything -- especially headers with ambiguous public vs. private behavior that people now depend upon
>  
> I get that. On the other hand I fear that we will be locked in place forever if we don’t allow breaking stuff once in a while. If at least we can get away with not exposing projects.h I think there will be much more room to play in the future. I hope that Even’s assessment about it not being used much is true.

Successfully burying projects.h would be enough to declare victory, if we can do so without upsetting too much. Even's analysis shows that might be possible. 

> > We need to be delicate about changing things for a library such as Proj.4 only for the sake of being "better". This is an unfortunate consequence of maintaining a library that everything ultimately uses (and started using 20+ years ago). 
>  
> Perhaps the ambition should be to BE MUCH BETTER than previous versions on PROJ.4. So much better that other projects will benefit hugely from using the new API and update their codebase voluntarily. Eventually the problem will solve itself. I already think we are on the right track.

#1: "It's ugly, but it works, it will stay working, and it requires no more software development"
#2: "It works more smoothly, but you have to write/update software to use it, and it does the same thing as #1"

There must be new features that incentivize the work required to do #2. For the sake of itself is not enough. Maybe access to transformation pipelines are enough for that, I don't know. It's a frustrating reality of a very old and well-established software project with lots of implementations. The success of Proj.4 has indeed locked itself in place.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170622/50c86a5f/attachment.html>