make 和 Cmake 实用程序是 Unix 从没有 IDE 并且 Consul(!) 打字机是终端的日子以来的遗留物。:-) 原则上，Unix-oids 仍然将这种方法用于开发和构建项目，作为最常见的方法。有时你离不开它，但它在现实生活中的份额正在减少。每个人都在 IDE 上工作，不会为 make 和 Cmake 烦恼。
您可能需要 Cmake 的另一件事是将程序作为开源分发。如果作者为项目提供了 Cmake，那么用户在他们的机器上重建项目就更容易了。在这种情况下，用户不需要弄清楚源在哪里、标题在哪里、库在哪里等等。如果您分发的项目不是 Cmake，而是 IDE 的配置文件，那么，首先，仅使用相同的 IDE 即可轻松重建项目。其次，用户机器上的 IDE 必须与项目作者的机器在同一个磁盘和相同的路径。
答案是“为什么”是显而易见的——因为 IDE 更易于使用。使用 IDE 时，您不必在每次将源文件添加到项目时手动编辑 CMake 配置。在 IDE 中，一切都在一个瓶子里——一个编辑器、一个调试器、一个编译器、语法突出显示、源代码格式化、错误突出显示、分析器等等。所有这些都不在 CMake 中，而且通常所有这些都不在通过命令行的旧开发方法中。这就是 CMake 被“逼入黑暗角落”的原因。这就是为什么 99% 的程序员只使用 IDE 工作的原因。
没有配置步骤。到目前为止，我不知道如何在工作室的 C++ 项目中指定它需要 VasyanLib，以至于在尝试构建项目时，工作室会询问我这个库的位置，而不是吐槽构建错误。
不重要。99% 的项目通过对库位置的静态引用来解决问题。如果它很关键，那么这个功能将被添加到 IDE 中。
在构建过程中很难使用第三方实用程序。例如，我有一个项目，首先构建一个 Haskell 程序，运行它，然后生成 C++ 代码，该代码已经变成了最终程序。在 CMake 上，花了 10 行，但在工作室我不知道如何实现它。
同样不是关键。99% 的项目在构建过程中不使用第三方实用程序。如果它很关键，那么这个功能将被添加到 IDE 中。预启动一个 Haskell 程序来写一个 C++ 程序供后续翻译，这样的 EXOTIC 不值一提。甚至没有 1% 的程序员以这种方式工作，0.00001% 的程序员以这种方式工作。是的，一般来说，即使是现在也没有人会在组装之前/组装之后通过使用第三方实用程序运行单独的批处理文件来中断。
所有提到的使用 IDE 的“不便”并没有超过使用 IDE 的“方便”。并且手动编辑 Cmake 的配置仍然是一种乐趣。此外，同时，记住这种鸟语配置的所有鸟规则。
应@pepsicoca1的要求，我正在写一篇详细的帖子。
编译器
首先是编译器。一个控制台程序，您提供一个带有代码作为输入的文件，它为您提供一个可以运行的二进制文件。对于类 Unix，它看起来像这样：
对于这样的 MSVC：
但是，任何或多或少复杂的项目都包含的不是一个，而是几个（很多！）带有源代码的文件。可以创建一个简单的脚本来编写它
但是，每次只更改其中一个代码文件时，都需要重新编译程序，此命令将重建所有 123 个文件。它很慢而且很不方便。需要一些东西来检测更改的文件并仅重建它们。
制作
一种这样的解决方案是
make. 如果说详细点，那么有几种方言make： Linux 使用所谓的。GNU Make，在 FreeBSD 上是 BSD Make，在 Windows 上是 NMake。make接受描述规则的文件作为输入。每个规则只是一个或多个生成某种文件的命令。规则可以使用其他规则执行产生的文件，从而形成依赖树。所有最终生成的文件都组合成一个规则all，因此该命令make all允许您“构建”整个项目。我将“编译”一词放在引号中，因为事实上，它
make不一定只用于编译器。make标题中的手册说：那些。
make- 这是一个用于管理依赖关系的程序，取决于什么并不重要。项目配置
麻烦并没有就此结束。C 和 C++ 语言的设计方式是，为了使用任何第三方库，您需要告诉编译器的路径
头文件由
-I类 Unix 操作系统上的标志/I和 Microsoft 编译器上的标志指定：同样，库的目录是用
-L/指定的/LIBPATH。但这很不幸——在不同的计算机上
VasyanLib，它可以安装在不同的目录中！这意味着如果您想将您的代码提供给其他人，或者只是在另一台机器上自己编译您的代码，那么您将不得不编辑您的构建脚本（读取，编译器调用命令）。如果您的构建脚本受版本控制（ , 等），这尤其不方便
git，hg因为svn您必须每次都提交这些更改，或者它们会“挂起”您未提交的内容。无花果将与它们一起使用库，但有时您需要找到编译器本身或某些文件。有时您需要确定操作系统的类型和版本、支持的编译器标志，并根据支持等添加一些。
因此，除了项目构建阶段之外，还会出现配置阶段。在这个阶段，在任何脚本或程序的帮助下，执行必要的检查和搜索，并将结果输入
Makefile（好吧，今天这个Makefile只是完整地生成）和/或格式化为头文件许多指令#define允许代码确定该文件或其他文件或功能的存在。装配系统
在这一点上，称为构建系统的软件的作用变得清晰。他们是
也许第一个构建系统是 Autotools。现在已经有很多了，在我看来， CMake是其中最通用的。其余的构建系统要么依赖于操作系统，要么依赖于编程语言。
CMake 与 IDE
现在，在考虑了整个历史之后，我们还可以分析 CMake 和构建系统是否总体上是“遗留”的问题，以及 IDE 是否绕过了它们。
答案是，当然不是。不仅可以在构建系统不断且积极地开发这一事实中找到这一点，而且还在于即使在不需要任何构建系统的 Visual Studio 中，也添加了对 CMake 的支持。
关于 Visual Studio 的几句话。这个 IDE 有它自己的项目格式，事实上，它有它自己的构建系统。Studio 项目在功能意义上相当于
Makefileam 或CMakeLists.txtam。在我看来，使用它们的不便之处如下：缺少配置步骤。到目前为止，我不知道如何在工作室的 C++ 项目中指出它需要什么
VasyanLib，以至于当我尝试构建项目时，工作室会问我这个库的位置，而不是吐槽 build错误。在构建过程中很难使用第三方实用程序。例如，我有一个项目，首先构建一个 Haskell 程序，运行它，然后生成 C++ 代码，该代码已经变成了最终程序。在 CMake 上，花了 10 行，但在工作室我不知道如何实现它。
哲学
实际上，不需要IDE 项目文件。
CMakeLists.txt因为这些文件已经是项目文件，所以不需要它们。此外，它们是通用的，不仅与操作系统相关，而且与使用的 IDE 相关——目前，除了 Makefile、Visual Studio 和 Eclipse 项目之外，CMake 还可以生成。在我看来，第一个理解这种深刻思想的 IDE 是KDevelop。原则上没有项目文件。从概念上看，这不仅是一个很酷的解决方案，而且具有实用价值——例如，KDevelop 以与 CMake 本身相同的方式“查看”项目文件。特别是，如果
#include你们中的一些人用红色下划线，那么这意味着你搞砸了 CMake 代码。而在工作室中，这个错误可能会被忽略，并且只出现在具有不同目录配置的另一台计算机上。希望这么详细的帖子能原谅KDevelop的无耻广告。但这是一个非常棒的 IDE，我花了很多时间开发。
需要 CMake（以及 make、qmake、gmake、consul 等）来描述构建项目的规则。也就是说，它旨在回答问题
此外，CMake 不仅仅是一种声明性描述，它是一种用于编写构建项目的代码的语言，而 CMake 已经有许多方法可以自动搜索库、当前架构等。
同时，CMake 文件比例如 Visual Studio 中的解决方案更具可读性和可理解性。
例如，在我的一个关于 arduino 的宠物项目中，我为 linux 组装了一个恶魔，为 arduino 组装了一个带有一个 CMake 文件的固件，并将这个固件上传到 arduino。
组织
C/C++一个项目。去官网https://cmake.org/就够了。要为微控制器创建程序，有时除了 make 和 cmake 实用程序别无选择。制造商的 IDE 将大量未使用的代码插入代码中，并且无法使用 IDE 工具将其从程序中删除。我必须在没有 IDE 的情况下构建一个项目。
make 和 Cmake 实用程序是 Unix 从没有 IDE 并且 Consul(!) 打字机是终端的日子以来的遗留物。:-) 原则上，Unix-oids 仍然将这种方法用于开发和构建项目，作为最常见的方法。有时你离不开它，但它在现实生活中的份额正在减少。每个人都在 IDE 上工作，不会为 make 和 Cmake 烦恼。
您可能需要 Cmake 的另一件事是将程序作为开源分发。如果作者为项目提供了 Cmake，那么用户在他们的机器上重建项目就更容易了。在这种情况下，用户不需要弄清楚源在哪里、标题在哪里、库在哪里等等。如果您分发的项目不是 Cmake，而是 IDE 的配置文件，那么，首先，仅使用相同的 IDE 即可轻松重建项目。其次，用户机器上的 IDE 必须与项目作者的机器在同一个磁盘和相同的路径。
TC没有问为什么。TS问为什么。TS 询问如果长期以来有方便的 IDE，为什么他和我们所有人都需要 CMake。我试图回答为什么现在，在 2019 年，可能需要 CMake。没有什么比开源项目的传播更有说服力了。
答案是“为什么”是显而易见的——因为 IDE 更易于使用。使用 IDE 时，您不必在每次将源文件添加到项目时手动编辑 CMake 配置。在 IDE 中，一切都在一个瓶子里——一个编辑器、一个调试器、一个编译器、语法突出显示、源代码格式化、错误突出显示、分析器等等。所有这些都不在 CMake 中，而且通常所有这些都不在通过命令行的旧开发方法中。这就是 CMake 被“逼入黑暗角落”的原因。这就是为什么 99% 的程序员只使用 IDE 工作的原因。
不重要。99% 的项目通过对库位置的静态引用来解决问题。如果它很关键，那么这个功能将被添加到 IDE 中。
同样不是关键。99% 的项目在构建过程中不使用第三方实用程序。如果它很关键，那么这个功能将被添加到 IDE 中。预启动一个 Haskell 程序来写一个 C++ 程序供后续翻译，这样的 EXOTIC 不值一提。甚至没有 1% 的程序员以这种方式工作，0.00001% 的程序员以这种方式工作。是的，一般来说，即使是现在也没有人会在组装之前/组装之后通过使用第三方实用程序运行单独的批处理文件来中断。
所有提到的使用 IDE 的“不便”并没有超过使用 IDE 的“方便”。并且手动编辑 Cmake 的配置仍然是一种乐趣。此外，同时，记住这种鸟语配置的所有鸟规则。
总的来说，总结一下，Unix 风格的汇编，以及丹尼斯·里奇父亲时代的 Unix 风格的工作，这是为老派一代准备的，他们在 make 和 Cmake 配置语言出现之前就设法学习了使用 IDE（顺便感谢这家令人难忘的 Borland 公司）。越远，这样的恐龙就越少，这是最好的。这些天没有人用代码编程。曾经有专家记住了整个 PDP-11 命令系统的所有代码（！）（甚至不是汇编程序助记符，而是 CODES）。:-)
这一切都很好，但是 99% 的项目不需要在不同的 IDE 和构建系统之间移植。因此，在 99% 的情况下不需要此 Cmake 属性。
一个非常可疑的说法。
以及如何使用 Cmake 帮助版本控制项目？此外，对于版本控制，现在使用同一个 git 等各种版本控制系统。这也不是命令行工具。
可以使用。或者可能没有使用。99% 的项目不使用 CMake。而且 99% 的程序员不使用 CMake。而且，这个数字只会增长得越多。问题来自一个快乐地生活在 IDE 下的人，突然发现还有 CMake。自然，他有一个问题 - 在此之前他是如何生活的并且没有使用 CMake 并且一切都为他工作？:-) 但是 CMake 的时代已经过去，CMake 只留给老卫兵，他们死了但没有放弃（С）拿破仑波拿巴。:-)
随着优秀的和不同的 IDE 的发展，CMake 和有福的命令行的作用一直在下降。:-)
看起来相当矛盾的是，TC 对答案相当满意，而公众继续义愤填膺地告诉 Cmake 是什么。问题不在于 Cmake 是什么，而在于为什么需要 Cmake，如果有 IDE 可以做 Cmake 可以做的所有事情，因此 IDE 使 Cmake 变得不必要。
汽车取代了马，IDE 完全取代了 Cmake。这被称为技术进步。你仍然可以骑手推车，但为什么呢？您仍然可以使用 Cmake 构建项目，但为什么呢？
嗯，很清楚为什么。事实上，有 1% 的项目需要跨不同的 IDE 和平台进行移植。对于这样的项目，也许使用 Cmake 是合理的。但现在不是主流。这是一个非常小众的应用程序。