compilation is broken on CentOS

[vladzcloudius]

HEAD: c1e0e5d6b461bdd314d2b190dc9e31ccd92fd6d1 OS version: CentOS Linux release 7.5.1804 (Core) In-box CMake version: 2.8.12.2

Description configure.py fails complaining about the CMake version:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.1.0 or higher is required.  You are running version 2.8.12.2

Traceback (most recent call last):
  File "./configure.py", line 891, in <module>
    configure_fmt(mode, cxx=args.cxx, cc=args.cc)
  File "./configure.py", line 227, in configure_fmt
    subprocess.check_output(args=['cmake', '-G', 'Ninja', '../../../fmt', '-DCMAKE_CXX_COMPILER=' + cxx, '-DCMAKE_C_COMPILER=' + cc], cwd=builddir)
  File "/usr/lib64/python3.4/subprocess.py", line 617, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['cmake', '-G', 'Ninja', '../../../fmt', '-DCMAKE_CXX_COMPILER=/opt/scylladb/bin/g++-7.3', '-DCMAKE_C_COMPILER=gcc']' returned non-zero exit status 1
Seastar configuration failed

Offending commit:

commit 502b1b488972ce983430d7d0d4bf1b3e896594d8
Author: Avi Kivity <avi@scylladb.com>
Date:   Sat Feb 3 19:22:45 2018 +0200

    build: compile libfmt out-of-line

    Switch to building libfmt as a regular library instead of a
    header-only library. This reduces compile time.
    Message-Id: <20180203172245.25575-1-avi@scylladb.com>

[vladzcloudius]

Reverting the offending commit fixes the issue.

[nyh]

Cmake 3.1.0 was released four years (!) ago - check out https://cmake.org/pipermail/cmake/2014-December/059418.html Centos 7.5 was released only a few months ago. What's going on? Is this a fiasco at the Python 2/3 level, where ten years (!) after the release of Python 3, people and distros are still wondering whether they should switch from 2 to 3?

[tchaikov]

@vladzcloudius probably you could use EPEL7 [1], and install cmake3 from it?

---

[1] https://centos.pkgs.org/7/epel-x86_64/cmake3-3.12.2-1.el7.x86_64.rpm.html

[vladzcloudius]

@tchaikov Yes, I can and I did - it installed an executable called cmake3 (cmake version 3.10.2) which still didn't resolve the problem since we try to invoke cmake.

This issue is not about hacking it but about our scriptology being broken. We rely on it when we build scylla project RPMs, during nightly builds, etc.

We simply need to make this work out-of-the-box (in conjunction with install-dependency.sh script invocation).

[tchaikov]

@vladzcloudius i see your pain now. probably we can have yet another

arg_parser.add_argument('--cmake', action = 'store', dest = 'cmake', default = 'cmake',
          help = 'cmake commmand use for building libfmt')

and pass it down to configure_fmt() ?

which allows user to specify the cmake command (or path). and in rpm.spec, it's relatively simpler to conditionalize the dependency depending on the distro and pass the correct --cmake option to configure.py

[vladzcloudius]

@tchaikov I'd prefer things to resolve automatically - this would not require us patch every place where we use it.

[tchaikov]

@vladzcloudius i am posting a tiny patch in hope to address this issue.