Thanks everyone, for the feedback on my CMake suggestion.

Ville Voutilainen said:
> It doesn't seem wise to standardize a build system that is loathed[1] by
> a substantial part of the C++ community.

Can anyone name any build system that isn't loathed by a substantial
part of the C++ community?

Boris Kolpackov said:
>...things work best if the build system and the package manager (or,
> more broadly, package/project dependency management) are tightly
> integrated into a build toolchain.

While not common practice, it can be done with CMake. I write CMake
build systems that download and build dependencies.

Corentin said:
> ...so that one can, for example, include a cmake project in a build2
> or meson project, or the other way around, we wouldn't need to force
> a build system on people.

CMake has a mechanism to call other build systems. That doesn't help.
The reason to standardize on CMake for tool makers is so tool makers
aren't expected to support every build system in the world, our present
situation.

> I think that cmake is terrible and that better options exist.

My support of CMake is pragmatic, that it is cross-platform and widely
deployed. Happy to consider something better. What are the better options?

> I'm interested in gathering feedbacks
https://hackernoon.com/undefining-the-c-pre-processor-c4eeb3d06e1f

My feedback is your white paper has a lot of great suggestions for
programmers. If I may summarize, it says that C++ programmers writing
code today should follow best practices and use newer C++ features that
were introduced to replace C pre-processer idioms.

For IDE tool makers, C++ best practices is relevant, can be used to
guide programmers writing fresh code.

Refactoring tool makers are confronted with legacy code that will not
have any of the recent C++ best coding practices because the code was
written earlier and some of it is in C.

Robin