Add Azure Pipelines configuration for CI builds using CMake

[mloskot]

This AzP provides comprehensive setup for CI builds:

• on Linux, MacOS, Windows
• compiling with
  • clang 3.5 - 8
  • GCC 4.9 - 8
  • Visual Studio 2017, 2015, 2019
  • Xcode 8.3.3 to 10.1
• targeting C++ standard versions: 11, 14, 17, 20 (2a)
• configuring with CMake 3.12.4 (Linux), 3.14.3 (MacOS), 3.14.4 (Windows)
• with CMAKE_BUILD_TYPE=Release

This configuration allows any contributor to set up CI pipelines with AzP at https://dev.azure.com/<owner>/geos and build directly from GitHub upstream (libgeos/geos) or own fork in order to test own topic branches as well the master.

---

/cc @dbaston

Sample build matrix available at https://dev.azure.com/mloskot/geos/_build/

[pramsey]

Does it really do all those combinations? Seems... like a a lot?

[dbaston]

Thanks @mloskot . For some reason I can not access the pipeline page on this PC (browser extension gone haywire) but I will check it out later to look at the output, build times, etc. Initial thought is that this should replace AppVeyor and Travis, so either needs to include autotools or wait until we are able to replace autools w/cmake. cmake versions should probably be set to the minimum (3.8 for Linux, higher for Windows). I'm also wondering why we test building w/C++14, 17, and 20 standards?

[mloskot]

@pramsey Yes, it pretty much does do it all with some exceptions like no C++11 in Visual Studio or may not be building C++11 with latest GCC/clang as time-to-build optimisation or some C++ versions may be skipped where not supported by the compiler version.

As you can see in my sample pipeline, it already helps to discover C++ portability issues.

In fact, there should be more:

1. Each build should not do just Release but Release and Debug.
2. Three additional builds using clang and UBSan for undefined, nullability and integer checks.

Something for future.

---

For numeric/float/bit intensive codebases, testing variety of compilers and versions of the same compilers and C++ language support within particular compiler version does help to find bugs.
For example, in one case of image processing library ~30 versions of compilers build fine, but one particular fail to compile or an optimised binary generated by a particular version is failing checksum-based tests at run-time, etc.

[mloskot]

@dbaston

Initial thought is that this should replace AppVeyor and Travis, so either needs to include autotools or wait until we are able to replace.

I am not going to propose to replace those.
I dedicate this as auxiliary CI setup for GEOS developers to test their patches from their forks in non-intrusive manner. I intentionally stick to CMake only. I intentionally did not add any badges to the README either.

I'm also wondering why we test building w/C++14, 17, and 20 standards?

GEOS requires C++11 only as minimum supported version.
It does not require C++11 as exclusively supported version.
Such requirement would be highly restricting and in fact very impractical.
For example, GCC 6.x and Clang 6.x (or later) already default to -std=c++14.

Users should be able to compile their GEOS clients as C++11 or any later version of C++.

[strk]

The pipeline page is not usable from mobile phone (but I've no objection with merging this)

[mloskot]

What's stopping the merge?