Is a modern build system acceptable for older platforms

There have been several discussions of replacing PG's autoconf +
src/tools/msvc system. The last example is happening now at the bottom of
the Setting rpath on llvmjit.so thread.

I see potentially big advantages to moving but also to PG's conservative
approach that keeps it running on edge and old platforms so I set to look
more carefully what could be problematic or a showstopper for a more modern
build system. Here are my findings, hope they help.

Unlike autoconf, all newer alternatives that I know of (certainly CMake and
Meson which were floated as alternatives so far) require themselves to be
present on the build machine when building. I know they have good reasons
to do this but that means they impose new dependencies for building PG.
Let's see what those are for CMake and Meson to get an idea if that's
acceptable and a feeling for how much friction they will introduce.

CMake
=====

* needs a C++11 compiler (since 3.10, before it used to only need C++98)
* needs libuv (since 3.10 apparently, I know that some years ago it had no
library dependencies besides the C++ standard library)
* has a make backend so no new depedency (it maybe works with non GNU make
so maybe it lowers one dependency)
* can bootstrap on a number of Unix systems, see
https://gitlab.kitware.com/cmake/cmake/blob/master/bootstrap

For the platforms in "CMake's buildfarm" see
https://open.cdash.org/index.php?project=CMake

The C++11 requirement caused 3.10 and higher to not build anymore for HP-UX:
https://gitlab.kitware.com/cmake/cmake/issues/17137

Meson
=====

* needs Python >= 3.4
* needs ninja
** meson has no make backend see
http://mesonbuild.com/FAQ.html#why-is-there-not-a-make-backend for rationale
** as a small positive, this would mean not having to explain "you need
GNU make, BSD make is not enough"

Ninja:
* needs C++
** I think C++98 is enough but not 100% sure, with a quick look at the
code I noticed no newer C++ features and the bootstrap script does not pass
any -std arguments to the C++ compiler so it should be 98
* https://github.com/ninja-build/ninja/pull/1007 talks about adding AIX
support and is in a release already
* https://github.com/ninja-build/ninja/blob/master/configure.py is the
bootstrap script which lists these as known platforms: 'linux', 'darwin',
'freebsd', 'openbsd', 'solaris', 'sunos5', 'mingw', 'msvc', 'gnukfreebsd',
'bitrig', 'netbsd', 'aix', 'dragonfly'

Python 3:
* points to ActivePython for HP-UX: https://www.python.org/download/other/
* some googling suggests Python > 3.2 works well on AIX and there are some
links to binaries

If I look at the requirements above versus what Postgres has in
src/template and in the build farm it seems like HP-UX and AIX could be the
more problematic or at least fiddly ones.

A related issue is that future versions of CMake or Meson could move their
baseline dependencies and desupport old platforms faster than PG might want
to but there one could make the case to just use the older meson or CMake.

So before the discussion whether the gains from switching build systems
would offset the pain, I think the project needs to decide whether a newer
build system is acceptable in the first place as it has a chance of
desupporting a platform alltogether or at least making it more painful for
some platforms by adding the bootstrap step for the build system with
potentially cascading dependencies (get Python 3 working, get ninja
bootstrapped, get PG built or get libuv built, get CMake built, get PG
built).

The above is all about getting the build system to work at all. If that
isn't a showstopper there's a subsequent discussion to be had about older
platforms where one could get the build system to work but convenient
packages are missing. For example not even RHEL7 has any Python3 packages
in the base system (it does in Software Collections though) which means
some extra hoops on getting meson running there. And RHEL5 is in an even
worse spot as it has no Software Collections, who knows if Python 3 builds
on it out of the box etc.