在 Windows 和 Linux 上构建 C++答案

【问题标题】：Building C++ on both Windows and Linux在 Windows 和 Linux 上构建 C++
【发布时间】：2010-11-09 13:32:42
【问题描述】：

我参与了针对 Windows 和 Linux (RHEL) 平台的 C++ 项目。到目前为止，开发完全是在 Visual Studio 2008 上完成的。对于 Linux 编译，我们使用了 3rd 方 Visual Studio 插件，它读取 VS 解决方案/项目文件并在 Linux 机器上远程编译。

最近决定放弃 3rd 方插件。

现在我最关心的是构建系统。我一直在寻找跨平台构建工具。这样我就不需要维护两组构建文件（例如 Windows 的 vcproj/solution 和 Linux 的 make 文件）。

我找到了以下候选人：一种。斯康斯湾。 cmake

您如何看待跨平台开发的工具？

还有一点让我困扰的是，如果没有 vcproj 文件，Visual Studio (+ Visual Assist) 会失去很多功能 - 你如何使用这些工具来处理这个问题？

谢谢迪玛

PS 1：我喜欢 Scons 的一点是它 (a) 使用 python，因此它很灵活，而 cmake 使用专有语言（我知道它不是构建系统的赢家功能） (b) 自包含（不需要像 cmake 那样在 Linux 上生成 makefile）。

那么为什么不是 Scons 呢？为什么在您的项目中决定使用 cmake？

【问题讨论】：

Out 系统旨在最多两个平台，所以问题是如果 cmake 不是“过度杀戮”？我担心的另一点是构建必须是可重现的（从头开始构建两次将完全提供 SAME 产品）。当然，使用本机构建系统我接近目标。 cmake 是否可能会破坏它并根据编译它的人的设置创建不同的 vcproj/makefile（例如，对于 Windows，每个开发人员都在其私人机器上进行编译）？
只是关于 Visual Assist 的说明。使用空解决方案时，它可以选择从目录加载文件。

标签： c++ build-process cross-platform cmake scons

【解决方案1】：

CMake 将允许您仍然使用 Visual Studio 解决方案和项目文件。 Cmake 本身并不构建源代码，而是为您生成构建文件。对于 Linux，这可以是 Code::Blocks、KDevelop 或普通的 makefile 或其他更深奥的选择。对于 Windows，它可以是其他 Visual Studio 项目文件，也可以是 MacOS 的其他项目文件。因此，Visual Studio 解决方案和项目是从您的 CMakeLists.txt 创建的。这适用于大项目就好了。例如。当前的 Ogre3d 在所有平台（Windows、Linux、MacOS 和 iPhone）上都使用 CMake，而且效果非常好。

不过，我在这方面对 scons 了解不多，我以前只构建一个库，而且只在 Linux 中构建。所以我不能在公平的基础上比较这两者。但是对于我们的多平台项目，CMake 已经足够强大了。

【讨论】：

CMake 非常好 - 它会重新生成 VS 项目文件，因此说“允许您仍然使用 ... 项目文件”是部分误导。我强烈推荐它用于 C++ 项目，作为唯一的解决方案，如果需要在包括 Windows 的许多操作系统之间兼容（Windows 是唯一的“困难”操作系统......），并且您还想使用 Visual Studio。跨度>
我希望我的其余回答能解决这个问题。 :) 你当然是对的。您现在拥有的解决方案文件将替换为生成的解决方案文件。 CMake 将向您的解决方案本身添加一些项目（ALL_PROJECTS、INSTALL、ZERO_CHECK），这些项目一开始可能会让人感到尴尬，但一旦您了解它们的用途，它们就会非常方便。特别是安装。它将构建解决方案的所有部分，并将 CMakeFiles.txt 中指定的创建的 DLL、EXE 和其他文件复制到其目标目录，以便您只需运行 NSIS 或其他包工具来创建安装包。
值得注意的是，SCons可以生成VS项目文件。

【解决方案2】：

我之前没有使用过 Scons，所以不能说它是如何工作的，但是 CMake 工作得很好。

它通过生成目标平台所需的构建文件来工作。

当用于面向 VC++ 时，它会从 VS 生成解决方案和项目文件，因此它们看起来就像是原生 VS 项目。当然，唯一的区别是，如果您直接通过 VS 编辑项目或解决方案，则更改将在您下次运行 CMake 时被删除，因为它会覆盖您的项目/解决方案文件。

因此必须改为对 CMake 文件进行任何更改。

【讨论】：

【解决方案3】：

我们有大量的核心库和基于这些库的应用程序。我们为每个项目或库使用 Visual Studio 解决方案在 Linux 和 Windows 上维护基于 Makefile 的构建系统。

我们发现它可以很好地满足我们的需求，每个库或应用程序都是在 linux 或 windows 上开发的，并考虑了交叉编译（例如，不要使用特定于平台的 api）。我们将 boost 用于文件路径、线程等内容。在特定情况下，我们使用模板/#defines 来选择特定于平台的解决方案（例如事件）。准备就绪后，我们移至其他系统（linux 或 windows），重新编译，修复警告/错误并进行测试。

我们没有花时间找出可以在两个平台上交叉编译的工具，而是使用最适合每个平台的系统，并花时间修复特定问题并使软件变得更好。

我们仅在 Windows atm 上提供 GUI 应用程序。所以没有交叉编译的GUI。我们在 Windows 和 Linux 之间共享的大部分开发是服务器端网络（套接字、TCP/IP、UDP ...），然后是 Linux 上的客户端工具和 Windows 上的 GUI 应用程序。

使用 perforce 进行源代码版本管理，我们发现在很多情况下，Linux Makefile 系统比 Windows VS 更灵活。特别是对于使用多个工作区（源代码版本的视图），我们需要指向公共目录等。在 Linux 上，这可以通过自动运行脚本来更新环境变量来完成，在 Visual Studio 上引用环境变量非常不灵活，因为很难在视图/分支之间自动更新。

重新同步问题：

我假设您问的是如何确保两个构建系统在 linux 和 windows 之间同步。我们实际上在 Linux 上使用 Hudson，在 Windows 上使用 CruiseControl（我们首先在 Windows 上使用巡航控制，当我去设置 linux 版本时，我认为 Hudson 更好，所以现在我们有了混合环境）。我们的系统一直在运行。当某些东西被更新时，它会被测试和发布（无论是 windows 还是 linux 版本），所以你会马上知道它是否不起作用。在测试期间，我们确保所有最新功能都在那里并且功能齐全。我想就是这样，不涉及任何黑魔法。

哦，你的意思是构建脚本......每个应用程序都有自己的解决方案，在解决方案中设置依赖项。在 Linux 方面，我为每个项目都有一个 makefile，并且在项目目录中有一个构建脚本来处理所有依赖项，这主要意味着构建核心库和给定应用程序所需的几个特定框架。正如您所看到的，每个平台都不同，很容易在构建脚本中添加行来更改目录并生成所需的项目。

这有助于以一致的方式设置项目。

在 Windows 上，您打开项目并添加依赖项项目。再次没有涉及魔法。我认为这类任务与开发相关，例如您向项目添加了新功能，并且必须链接到框架和标题中。因此，在我看来，没有理由将这些自动化 - 因为它们是开发人员在实现功能时所做的一部分。

【讨论】：

如果你说你如何确保各种构建脚本不会不同步，我会投赞成票。（持续集成服务器是一种方式）

【解决方案4】：

另一种选择是预制。就像 cmake 一样，它从定义文件生成解决方案。它是开源的，最新版本可以使用 Lua 脚本进行高度定制。我们能够毫不费力地添加自定义平台支持。对于您的情况，它支持 Visual Studio 和 GNU makefile 标准。

见Premake 4.0 Homepage

CruiseControl 是持续集成的不错选择。我们已经成功地使用 Mono 在 Linux 上运行它。

【讨论】：

我不推荐 premake，因为与 CMake 和 SCons 这几个主要项目相比，它缺乏知名度/社区/支持。

【解决方案5】：

这是一个article，关于 KDE 开发人员选择 CMake 而不是 SCons 的决定。但是我必须指出，这篇文章已经快三年了，所以 scons 应该有所改进。

Here 是 SCons 与其他构建工具的比较。

【讨论】：

另请注意，SCons 更通用，而 CMake 偏向于特定语言。

【解决方案6】：

过去经常这样做。我们所做的就是将 gnu make 用于几乎所有东西，有时包括 windows。

如果您愿意，可以使用 windows 下的项目文件并使用 gnu make for Linux。

编写跨平台 makefile 并没有真正好的方法，因为目标文件将在其他方面有所不同（以及路径名问题，\ vs / 等）。一般来说，您可能会在各种平台上调整代码以考虑到细微的差异，因此必须对 make 文件进行调整并检查其他平台无论如何。

许多 OS 项目为不同平台维护 Makefile，例如 zlib，它们被命名为 Makefile.win、Makefile.linux 等。您可以效仿他们。

【讨论】：

在你的方法中使用 CMake 之类的东西有什么优势？使用 CMake，您只需管理一组构建文件，仍然可以充分利用您最喜欢的 IDE。
一个优点是它可能更容易为每个系统使用标准脚本，而不是找出一个跨平台脚本以某种方式解决所有操作系统的任何怪癖。不过，仍然需要大量的重复工作......