Re: WIP: About CMake v2

On Fri, Feb 10, 2017 at 5:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> But also, I'm not really sure whether this conversion makes sense. I
> mean, any build system is going to require some work, and accordingly
> our present build systems require some work. cmake will require
> different work, but not necessarily less. The current system has a
> long history; we pretty much know it works. Switching will inevitably
> break some things. Maybe we'll end up better off in the long term,
> but maybe we won't. Things are pretty good now, so it seems like it
> would be easy for them to get worse rather than better. If nothing
> else, everybody who has to learn the new system either to use it for
> development or because they are doing packaging will have to do some
> amount of extra work as a result of any switch.
>

For what it's worth (even well-maintained) cmake is a usability regression
from well-maintained autotools from syseng/packager perspective.

Two anecdotes:

- ./configure is much nicer from user perspective. Compare:
./configure --prefix=/bla --enable-foo --disable-bar --with-ssl=/opt/myssl
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BLAH -DCMAKE_FOO
-DCMAKE_WHO_KNOWS_WHAT:PATH=/opt/myssl

- Things like set(_PYTHON3_VERSIONS 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
<https://github.com/Kitware/CMake/blob/master/Modules/FindPythonInterp.cmake#L43>
Guess what, on older cmake versions this list did not include anything
older that 3.3, so it was failing with in-comprehensive generic "not found"
error even though 3.4 was installed.
With this "fix" somebody somewhere will be banging their head against the
wall again once 3.8 is out.
Overall, when things go wrong debugging cmake requires cmake knowledge,
while autotools mostly require shell knowledge which is much more common
(again, for sysadmins/packagers).

So while cmake is better for developers it is usually worse off for
packagers and advanced users. I'm not saying migration is not worth it, I'm
pointing out costs of such migration.

PS: I personally like Google's internal version of https://bazel.build/ a
lot. I've never used open-source version but I presume it's similar. While
it has many problems (Java, lack of popular IDE support, lack of popularity
and, again, Java) good parts are rules are both machine- and human-
readable and writable and generally easy to debug. I'm not bold enough to
propose PostgreSQL to use it, but I'd be happy to see ideas from it to be
used elsewhere.

--
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047