在Windows和Linux上构建C ++

Question

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

最近决定放弃第三方插件。

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

我找到了以下候选人： 一个。 scons的 湾cmake的

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

令我困扰的另一点是Visual Studio（+ Visual Assist）在没有vcproj文件的情况下会丢失很多功能 - 你如何处理这些工具的问题？

由于 迪马

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

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

Answer 1

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

我对这方面的scons知之甚少，但我过去常常只在Linux中构建一个库。所以我无法在公平的基础上比较这两者。但对于我们的多平台项目，CMake足够强大。

Answer 2

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

它的工作原理是生成您要定位的平台所需的构建文件。

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

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

Answer 3

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

我们发现它适合我们的需求，每个库或应用程序都是在Linux或Windows上开发的，并考虑到交叉编译（例如，不要使用特定于平台的API）。我们对文件路径，线程等内容使用boost。在特定情况下，我们使用模板/ #define来选择特定于平台的解决方案（例如事件）。什么时候准备好了，我们转移到另一个系统（linux或windows），重新编译，修复警告/错误并测试。

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

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

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

重新同步问题：

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

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

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

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

Answer 4

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

请参阅Premake 4.0 Homepage

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

Answer 5

这是关于KDE开发人员选择CMake over SCons的决定的article。但是我要指出这篇文章差不多有三年了，所以scons应该有所改进。

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

Answer 6

过去不得不这么做。我们所做的是使用gnu make几乎包括窗口在内的所有东西。

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

编写跨平台makefile并不是一个很好的方法，因为目标文件会 与其他事物不同（和路径名问题，\ vs / etc）。一般情况下，您可能会调整各个平台上的代码以考虑细微的差异，因此必须对make文件进行调整并检查其他平台 反正。

许多操作系统项目为不同的平台维护Makefile，例如zlib，它们的名称类似于Makefile.win，Makefile.linux等。你可以跟随它们。