SCons或CMake而不是qmake

Question

我在以下问题上需要一些建议：

我有一个QT项目，目前设置为与qmake很好地配合。但是，由于项目的需求和未来方向的扩展，我需要更改它的构建系统，因为应用程序将需要对其构建方式进行一些更改。

现在每个源文件都被编译成一个非常大的可执行文件，这是打包（手动）并发送到下载区域。一切都很好。

但我的目标是模块化应用程序，将每个“功能”编译成共享库，用户（开发人员）将能够选择他想要编译的组件。这些“功能”放在源代码树的目录中（例如：query_builder，reverse_engineer，mysql_DB_support，version_managemen目录等等），当用户构建应用程序时，他只是告诉构建系统使用查询构建器编译应用程序和mysql，但没有逆向工程师，在这种情况下，构建系统从指定目录添加源文件并从中创建一个lib。

我还有其他要求，例如：

• windows build，linux build
• 可选包构建（deb，rpm）
• 支持QT，可能还有QT5
• 多个可执行文件（GUI客户端，CLI客户端）

经过一些“市场调查”后，我最终将CMake和SCons作为我可能使用的两种可能的系统。我有一些CMake经验和一些python经验，但还没有SCons。

但我不知道哪一个最适合我的情况，这是我需要你帮助的地方。你能详细说明我应该使用哪一款？如果您认为我的要求可以通过qmake实现，请告诉我，

干杯， F。

Answer 1

这个问题没有正确的答案，它通常归结为个人偏好，有点像vi和emacs（正确的答案是vi，当然：）

您应该研究每种方法的优缺点，并评估它们如何符合您的要求和需求。

我偏爱SCons，主要是因为我无法忍受CMake语法，但这是个人偏好。以下是我看到的各种优点和缺点：

的 CMake的 的

<强>优点：

• 与QMake类似，认为它是一个makefile生成器
• CMake被广泛使用，因此有很多参考和帮助
• 有一个GUI（我自己不知道，基于下面的Calvin1602评论）

<强>缺点：

• CMake有自己的，发明的语法，许多人认为（包括我自己）不直观。
• 2步构建过程，首先创建Makefile，然后实际执行编译
• 它几乎无法读取生成的Makefile

的 SCons的 的

<强>优点：

• 语法是Python，它被广泛使用并且相对容易学习。 （而且很酷:)：
• 构建过程是一步，只执行SCons，然后编译。没有要生成或维护的中间构建文件。
• 在过去SCons比CMake慢，但从那时起它速度要快得多，可能比CMake快或快，因为它不需要生成makefile。
• 丰富的功能集，支持多种语言，而CMake专注于C / C ++
• 非常准确的隐式依赖系统：无需显式列出依赖的头，库等。如果需要，可以指定显式依赖。
• 可以使用eclipse插件。 Eclipse还有可用于Python的插件。
• 为Qt项目创建了工具来处理MOC和其他相关的codegen here。

<强>缺点：

• SCons可能没有像CMake那样广泛使用，但仍然有很多支持。
• 根据项目的大小，SCons可能会使用大量内存，因为它会解析所有构建脚本，并在实际编译任何内容之前在内存中构建依赖树。但这确实允许更准确的依赖性检查。