About CMake: We can use 3.9 version very well, it has all features for us, at least for my postgres_cmake branch and I have the experience to introduce features to cmake special for postgres build. Also, cmake very easily build even for Solaris or AIX (on my webpage I have examples to build postgres with cmake on this systems).
But, I totally agree with this topic, we can't keep same support matrix and can't keep 100% same behavior and a "build" interface. Maybe, behavior should be the second question. In my opinion, I made too much now without the answer to this important question. 2018-04-19 14:30 GMT+09:00 Catalin Iacob <iacobcata...@gmail.com>: > 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. >
