Re: Is a modern build system acceptable for older platforms

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 <iacobcatalin(at)gmail(dot)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.
>