Re: would it be time to replace scons with meson build system?

[Greg Troxel]

Claus Klein <address@hidden> writes:

> Do you mean, you can’t build cmake itself?
>
> Than, you are right, but most modern C++ projects (ninja too) are working 
> based on C++11 and newer!

I can build it now.  This was at an earlier time, on an earlier system,
and I don't remember the exact issue.  I just remember pain, and that
not having cmake build would result in the failure to build of a large
number of other packages.

It is true that most projects in C++ are using C++11.  If you want to
build something large and complicated like qgis, then cmake is not a
significant incremental barrier.

What I am talking about is imposing the requirement for the modern and
rapidly changing C++ compiler setup on programs that *do not already
depend on C++11*, like gpsd.

> C++20 is coming soon!!!

Yes, C++ is an unstable language (or an unstable family of stable
languages, to be pedantic), and it's difficult to deal with projects
using it that adopt the new languages faster than compiler support
arrives in non-rapidly-updated systems.  I don't think this is a good
thing.

Keep in mind that the process is solidification of the specification,
release of a compiler with support, release of the .1 version of that
compiler, adoption of that compiler into the base of an OS, release of
that OS.  This means that "maintained version of OS must necessarily
support language X, or we can call it unacceptably lame or unacceptably
old" does not happen until considerable time after the freezing of the
language spec.  For C++11, I'm not sure exactly when we got there
happened, but I'd say 2019 is a good guess, maybe 2018 or possibly 2017,
but not earlier.

So my point is

1) For programs that don't already have a hard requirement for C++11,
using cmake as a build system means that the program inherits that
requirement (for native builds).

2) cmake adopted C++11 at a time that was premature, in my view, because
cmake is needed to build a very large number of projects, and thus
should not orphan any semi-reasoable system.

3) Given cmake's willingness to change to newer C++ sublanguages, I see
it as unsuitable for projects that don't have the same willingness to
require those newer languages.  What confidence do we have that cmake
will not start requiring C++14 or C++17 to build?