Is a modern build system acceptable for older platforms

Поиск
Список
Период
Сортировка
От Catalin Iacob
Тема Is a modern build system acceptable for older platforms
Дата
Msg-id CAHg_5grEV_gT0845XbEQXYMPJichVKL74J5_m4bMr-4+rMzyzw@mail.gmail.com
обсуждение исходный текст
Ответы Re: Is a modern build system acceptable for older platforms  (Yuriy Zhuravlev <stalkerg@gmail.com>)
Re: Is a modern build system acceptable for older platforms  (Darafei "Komяpa" Praliaskouski <me@komzpa.net>)
Re: Is a modern build system acceptable for older platforms  (Yuriy Zhuravlev <stalkerg@gmail.com>)
Re: Is a modern build system acceptable for older platforms  (Yuriy Zhuravlev <stalkerg@gmail.com>)
Список pgsql-hackers
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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: Corrupted btree index on HEAD because of covering indexes
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: reloption to prevent VACUUM from truncating empty pages at theend of relation