[Proj] Coming releases of PROJ.4

[Howard Butler]

> On Jun 25, 2017, at 9:22 AM, Charles Karney <charles.karney at sri.com> wrote:
> 
> On 06/22/2017 03:55 PM, Howard Butler wrote:
>> 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 certainly appreciate the point that functionality (in this case,
> autotools configuration) shouldn't be needlessly withdrawn.  However,
> maintaining both cmake and autotools configurations entails ongoing
> maintenance costs and I, for one, wish that autotools could be slowly
> replaced by cmake.

I don't like CMake's configuration language anymore than m4 to be honest, but I agree that CMake is a best-of-the-worst configuration tool, especially for cross-platform operations.

> 
> The big benefit of cmake is that it's cross-platform.  Even though it
> has its warts, it handles package dependencies in a (more or less)
> uniform way, it's actively maintained, etc.
> 
> autotools is Unix only, depends on the m4 language that hardly anyone
> knows, and the whole mess seems to be duct-taped together.  Its big
> advantage is that it's been around for longer.
> 
> So my question is: aside for simple inertia (which I understand!), what
> is stopping the Unix/Linux world adopting cmake?  Is there really
> something about autotools that's superior to cmake for maintaining
> packages on Linux distributions?

Superior is maybe an imprecise term. I think the situation is the distribution packagers have adapted all of their build configurations to dovetail with autoconf/automake's quirks, and CMake has to mimic these things to be a drop-in replacement. Cross-compilation targets, special configuration variables, and and output install locations are all areas where CMake doesn't always behave or can't be made to behave exactly in the same way as autotools. 

A library that already has autotools support, especially one as foundational as Proj.4 now is, has a ring of configuration logic implemented by all of the packaging system for the myriad of distros. Many have built that with our autotools configuration, and if we were to yank that away now, we are likely to disrupt them. If we had started with CMake from the beginning, this wouldn't have been a problem, of course.

Feedback from the distro packagers if this sentiment is contrary to reality would be appreciated. Maybe Proj.4 dropping autotools wouldn't be a big issue, but it would certainly ripple changes across a lot of distributions.

Howard