[PROJ] Bump CMake version for PROJ 7.0

[Howard Butler]

> On Jan 31, 2020, at 9:28 AM, Greg Troxel <gdt at lexort.com> wrote:
> 
> Howard Butler <howard at hobu.co> writes:
> 
>> +1
>> 
>> I wonder if we could increase the minimum CMake requirement
>> significantly further due to the fact that PROJ supports both CMake
>> and autoconf for now. Do the packagers have an opinion on the topic?
> 
> I was going to comment that a proposal with no analysis and no rationale
> was a little odd...

https://cliutils.gitlab.io/modern-cmake/chapters/intro/installing.html#cmake-default-versions is a good breakdown. 


> 
> My opinion is that it's not a good thing to increase the required
> version of dependencies for no good reason, unless it is truly free.
> So I would look at the places one might want to build proj and see how
> old cmake might be.

The cost of old cmake configuration is a consideration too. PDAL, for example, was one of the first geospatial projects to be CMake-only, and our configuration has a lot of cruft as CMake continued to rapidly evolve in fits and starts through 3.0 – 3.10. Packagers have complained about missing features, misbehavior, and frustration, especially for older configurations. It would be best for PROJ to not proliferate old configuration in support of old CMake if it can be avoided.

Compatibility with no disruption of how autconf was working was the desire expressed previously. Since PROJ is still maintaining its autconf configuration, I thought the minimum CMake version could be significantly bumped. Are the packagers using CMake or autoconf? In Conda Forge[1], for example, we are using both – autoconf for linux/osx and cmake for win64 

[1] https://github.com/conda-forge/proj.4-feedstock/tree/master/recipe

Howard