Talk:CMake

Archive reasons for removal

CMake is starting to turn the corner. It is not where we want it but it has improved a lot since the community started helping out.

We are yanking the reasons for removal because it was paramount to bashing; and archiving it here.

The experiment failed for several reasons. First, CMake is a redundant build system because the Makefile is used on Unix & Linux; and Visual Studio & MSBuild are used on Windows. CMake users could integrate the library by using ExternalProject_Add. There was no reason for us to provide CMake to create Makefiles and MSBuild files we were already providing. We were doing over twice the amount of work than we needed to be doing. Also see CMake link to external library on Stack Overflow.

Second, CMake was consuming disproportionate amounts of our time. It accounted for over 18% of bug reports in the issue tracker. When an issue was encountered, it was often non-trivial to find a solution. Even simple workflows, like "add a flag to CXXFLAGS" or "add a flag to LDFLAGS" were complicated. Based on Current Status below there was no end in sight.

Third, CMake uses an insecure configuration for release builds. All CMake projects are vulnerable to CVE-2016-7420 -like findings if the project uses the default options provided by CMake. Secrets that Crypto++ may protect could be egressed because of the CMake's insecure configuration (which have nothing to do with the Crypto++ configuration). Additionally, CMake does not use required platform flags, like -mfloat-abi=softfp for armeabi builds on Android.

Fourth, CMake did not provide a cross platform way to get a shell for testing. We had to prepare arguments for a call to exec or CreateProcess. It also meant we could not do thing like assign sh -c to a variable and call through it. Also see Avoid egrep when possible, remove egrep from DumpMachine in the Crypto++ issue tracker.

Fifth, CMake makes it difficult to impossible to change flags it wants to use, like -O2. Vectorization gained widespread support in the mid-2000's. The library has a lot of code and patterns to take advantage of it. To engage vectorizations we need -O3 for compilers like Clang, GCC and Intel ICC. Unfortunately, CMake has forced us to use their poor selection.

Sixth, CMake lacked good native support for AIX, Android, iOS, PowerPC, Solaris, Windows Phone, Windows Store, SSE, ARMv7, ARMv8 and Power8. We had to do nearly everything manually, and it placed too much of a burden on the library maintainers.

Seventh, we could not query CMake and user options in a particular configuration to further tune our use of flags and options. Also see Difference between add_compile_options and SET(CMAKE_CXX_FLAGS…) on Stack Overflow.

Eighth, CMake had too many bugs that went unfixed and required too many work-arounds. For example, we were never able to set project(cryptopp, CXX) because CMake could not perform its tests with a C++ compiler. Two years later the bug was still not fixed. Also see Tell CMake to use C++ compiler for C files coming from CMake? on Stack Overflow. Another example is How to have CHECK_CXX_COMPILER_FLAG fail on illegal value? on Stack Overflow, where the compiler would report an illegal option but CMake would report success. Yet another example is How to strip trailing whitespace in CMake variable?, where STRIP does not strip whitespace.

Ninth, CMake uses anti-patterns, like not driving link through the compiler. Best practice dictates using the compiler driver for link. The compiler driver will pass necessary options and libraries to the linker. CMake failed to honor the practice or supply the equivalent functionality. Also see Instruct CMake to use CXX and CXXFLAGS when driving link? on Stack Overflow.

Tenth, CMake hides output that is necessary for users to confirm their configuration and report bugs to the library. Nearly every bug report received had 1%, 2%, 3%, etc. Nearly every report lacked information we request, like a typical compile command and the link command. Its yet another example of making the "common case" difficult.

Eleventh, its impossible to comply with best practices and policies. For example, we started catching policy violations for quoting CMake variables. We removed the quotes to comply with policy, which subsequently broke Windows because of spaces in pathnames. Also see How to use variables and avoid CMP0054 policy violations? on Stack Overflow.

Twelfth, the documentation sucks. We did not know how to approach many workflows or treat most problems. Simple workflows, like "change release optimizations from -O2 to -O3" , were not documented and lacked exemplary code. When we experienced a problem it was hard to find a solution. We spent hours in their manuals without learning how to do much of anything.

Thirteenth, the CMake mailing list sign-up was disabled. We could not join the list and ask questions.

Fourteenth, no one stepped up to maintain it. Part of the agreement in adding CMake support was the community would maintain it. Once the initial files were added the Cmake supporters mostly disappeared. The library maintainers then had to field the bugs.

Also see Remove CMake from GitHub; add it to Patch Page on wiki? (mailing list), Commit 1c740b0a097aecaa (warning message) and Commit 913a9e60d375e458 (library removal).

Crypto++ was not the only project to suffer chronic CMake problems. See, for example, Monero Issue 771, Windows not bundling OpenSSL statically.

Jeffrey Walton (talk) 23:22, 26 August 2018 (UTC)