logo标签列表

在Linux和Windows上同时进行C++开发

c++cross-platform
12

我们有一些开发人员正在从事一个非商业（即仅供娱乐）跨平台C++项目。我们已经确定了所有我们需要的跨平台库。但是，有些开发人员更喜欢使用Microsoft Visual C ++ 2008，而另一些则更喜欢在GNU / Linux上使用Emacs编写代码。我们想知道是否可能让我们所有人都能从同一代码库中以更或多或少同时地在这两个环境下工作。最终，我们希望该项目能够从一开始就在这两个平台上编译通过。

如果这不可能，我们的任何开发人员都乐意切换到其他环境。我们所有人都定期使用Linux和Windows，并且都喜欢这两个平台，因此这不是试图向一个集合的开发人员传授另一个平台优点的问题。这是关于我们每个人都能够在自己最喜欢的环境中进行开发，同时在一个有趣的项目上进行协作。

是否有任何建议或经验可以分享？

13个回答
15

使用CMake管理您的构建文件。

这将使您设置单个仓库，并在其中放置一组文本文件。每个开发者可以运行相应的CMake脚本，为其系统构建正确的构建环境（Visual Studio 2008/2005/GNU C++构建脚本等）。

这里有许多优点：

  • 每个开发者都可以使用自己的构建环境
  • 依赖项可以非常干净地处理，包括特定于平台的依赖项。
  • 构建可以是无源代码的，这有助于防止意外提交不适当的文件
  • 轻松迁移到新的开发环境（例如：当VS 2010发布时，一些开发者可以通过重建其构建文件夹来迁移）
我喜欢这个建议，尽管我偶尔对makefile语法不屑一顾。我想再进一步（也许已经暗示了），建议你为每个目标平台设置CI构建。这样可以快速识别破坏构建的变更。市面上有很多CI服务器 - 我曾多次成功地使用Hudson来实现这个目的。 - Mike Ellery
如果您正在使用CMake，那么将其与CDash集成非常容易-这使您可以在多个分布式平台上执行CI或夜间构建，并提供漂亮干净的Web界面：http://cdash.org/ - Reed Copsey
@Mike：另外，我认为Cmake的语法比Makefile的语法更加简洁，并且完全消除了任何需要修改Makefile的必要性——如果您选择该生成器，它将为您生成Makefile（尽管我通常使用针对IDE的生成器）。 - Reed Copsey
我们在这类型的开发中已经使用CMake一年以上了。它很棒。我也用它来进行仅限于Windows的开发，语法易懂，而且使用CMake比在VC++中的所有对话框中重构项目结构要容易得多。其中最好的特点之一是你可以将常用的包含/链接路径、预处理器定义和库抽象出来，因此它们在解决方案中的所有项目中都只需指定一次。然后改变其中一个变得很容易，不再需要用文本编辑器更改20个项目文件。 - iain
12

我已经做过这个，而且也看到其他人也做得不错。

你需要尝试隔离不同平台之间的代码差异，并考虑你的目录结构。例如：

  • project/src <- .cc 和 .h 文件
  • project/src/linux|win <- 专门针对某个平台的代码
  • project/linux <- make 文件和其他项目相关内容
  • project/win <- .sln 和 .csproj 文件

基本上，你需要清楚每个系统所特有的内容和共同点。

此外，单元测试非常重要，因为可能会存在一些细微差异，你希望让Windows用户轻松运行一些测试来确保Linux代码按预期工作，反之亦然。

此外，单元测试也很重要。请注意，这意味着您需要确保您的单元测试框架也是跨平台的 - 例如避免使用内置于VS2012中的新C++单元测试框架。 - JBentley
5
如前面的帖子中提到的，Qt是一种非常简单的方法，可用于实现真正的多平台开发，而且不受IDE和许多不同编译器（包括Symbian、ARM、Windows CE/Mobile等）的限制。
在我所在的公司，我与混合的Linux和Windows开发团队一起使用Subversion和Qt开发（Qt有一个非常易于使用且功能强大的构建系统“QMake”，它隐藏了所有不同的平台/编译器特定的构建环境 - 你只需要为所有平台编写一个构建文件-非常容易！）。
而且：Qt几乎包含您需要的所有内容：
- 简单的字符串处理，具有易于翻译支持和易于字符串转换（utf8、utf16、asci...） - 简单的文件I/O、图像、网络等类 - 舒适的GUI类 - GUI布局/设计的图形设计工具 - 动态翻译应用程序的图形翻译工具（您可以运行一个二进制文件，以不同的可选择语言运行-甚至是西里尔文、亚洲字体等） - 集成测试框架（单元测试）
因此，Qt是一个功能齐全、非常可靠的环境 - 我已经使用它10年了。
并且：Qt可以无缝地集成到IDE中，如VC++、Eclipse或提供其自己的IDE“QtCreator”。
请参阅：http://www.trolltech.com + http://doc.trolltech.com 最好的问候， Chris
4
我有在Acronis工作的经验。我们使用相同的代码库来构建针对Win32/64、Linux和OS X（以及一些其他更奇特的平台，如EFI）的二进制文件（实际上是完全打包的安装程序），每个人都可以使用他们喜欢的IDE进行工作。这里的诀窍是避免编译器和IDE特定的解决方案，并通过清洁的跨平台make文件使项目能够完全构建。请注意，您可以与VC++一起使用任何make系统，因此这不是一个问题（出于历史原因，我们使用了Watcom make，但我不建议这样做）。
另一个技巧是添加一个制作脚本，根据您的makefile中的输入列表自动生成所有IDE（例如VS和Eclipse CDT）的项目文件。这样，每个开发人员都会为自己生成该内容，然后在IDE中打开这些项目以进行编辑/构建/调试，但源存储库中仅有makefiles。
确保代码可供每个人编译可能是一个问题，主要是因为VC++通常比g++更宽松地应用规则（例如，它将允许您将rvalue绑定到非const引用，尽管有警告）。如果您使用"将警告视为错误"，并使用最高警告级别（也许禁用了一些手动选择的警告），您将大多数情况下避免这种问题。设置连续滚动的构建集是早期发现这些问题的另一种方法。Acronis中我们使用的另一种方法是让Windows构建环境具有基于Cygwin的交叉编译工具，因此任何Windows开发人员都可以从他的计算机上进行面向Linux的构建（具有相同的g++版本和所有内容），并查看是否会失败，以验证他的更改是否在g++中可以编译。
3

我个人使用cmake/mingw32/Qt4来满足我的所有C++需求。 QtCreator是一个跨平台的IDE，它在一定程度上针对qt4编程进行了优化。

3
我们也在进行跨平台项目开发。我们使用Emacs编写代码，使用SCons进行构建，使用Visual Studio 2008进行调试。这是我第一次使用Emacs和SCons，我必须说一旦你弄清楚了SConstruct和SConscripts的工作原理，它非常非常方便。
3

我来晚了，这里有很多好的回答，但我还没有看到有人列举出我遇到的所有问题（我的大部分C++工作都是跨平台的），因此：

  • 跨平台编译。这方面已经有很多人讨论过了。CMake和SCons等工具都很有用。
  • 平台差异。这些问题不仅限于Linux和Windows之间的差异。不同版本的Windows也存在很多微妙的问题。如果你想从Linux转到OS X，你会发现情况也是如此。处理器架构的差异也是如此：32位和64位通常并不重要，直到某些事情出了问题，然后你会遇到非常严重的问题。这是C++程序员比大多数其他语言更容易面临的问题，因为它们的实现正在努力将这种事情从程序员那里隐藏起来。
  • 测试一切。Alan 提到了单元测试，但我想强调一下。跨平台编程的真正问题不是代码无法编译：而是即使代码在微妙的情况下编译得很好，但却做错了事情。在这里，单元测试比你在单个平台上工作时更加重要。
  • 尽可能使用可移植库。正确地完成这项工作充满了微妙的陷阱。最好利用别人的工作成果，而不是自己重新造轮子。Qt在这方面很有用，NSPR和APR（后两者是C语言的，但如果你不想直接处理它们，也可以使用包装器）。这些库明确将平台抽象作为目标，但你使用的大多数其他库也应该检查一下是否具有可移植性。对于没有可移植记录的酷炫库要有合理的警惕心态。我并不是说不要使用它们：只是先进行测试。正确地完成这项工作可以节省大量测试工作。
  • Pavel 提到了持续集成。如果只有少数几个人，这可能并不重要。但是，当你考虑所有的操作系统、操作系统变体和处理器差异时，会发现缺少某些边缘案例。如果你的项目超过了少数几个人，请考虑这样做。
  • 版本控制。最明显的问题是处理换行符和文件名大小写敏感度等问题，但还有其他问题。大多数知名的开源版本控制系统现在都做得很好，但值得注意的是，通常需要几年时间才能找到所有与可移植性相关的错误。例如Mercurial曾经是其卖点之一的可移植性，但在处理Windows文件名的不常见情况时，需要进行三到四个版本的修复。确保你能够及早检出其他人检入的内容。
  • 脚本。使用Perl/Python/Ruby（或类似的工具）进行脚本编写。试图让Linux shell和Windows批处理脚本保持同步是非常痛苦的。
尽管以上所有情况，跨平台总体上是完全可行的，没有真正的理由避免它。我的经验是问题往往会零星出现，但当它们出现时，需要花费比预期更多的时间来解决。不过，如果您已经有一段时间在编程，就不会觉得这是不寻常的。
2

支持cmake。

需要注意的一点是，在Windows上，文件名区分大小写，但不区分大小写。在大多数Unix文件系统上，它们是区分大小写的。 这通常是#include的一个问题。

例如：给定一个名为FooBar.h的文件。

 #include "foobar.h" // works on Windows, fails on Linux.
2
问题并不在于编辑C++源文件，而是构建过程本身。VS并不使用与Linux开发通常使用的Makefile架构相同的方式。一个激进的建议是，两个组都可以使用相同的C++ IDE和构建过程-有关更多信息，请参见Code::Blocks。
但它可以做到：创建一个Makefile项目，并运行您想要的任何命令行（不仅限于NMake，尽管这是默认设置）。 - Roger Lipscombe
1
我认为人们不会那么容易妥协，对于一些人来说，编辑器的选择似乎与选择宗教一样重要。这个问题在互联网上引发了虚拟战争，所以请注意你的建议！我们不希望Vi教派对抗Emacs教堂！（尽管我们知道Vi教派肯定会轻松击败Emacs教堂）PS：请不要太认真对待这个问题，只需记住大多数开发人员不会轻易放弃他们心爱的编辑器 :) - user118861
嗯，这个建议并不是很认真的 - 我知道 Emacs 用户的性格 :-) - anon
2
这是可能的（我这样做是为了赚取我的日常收入 :-)）。
但是您必须记住操作系统提供的库之间的差异可能非常恼人。 解决这个问题的两个好选择是BOOST和QT。
两者都提供了平台无关的有用功能函数，这些功能不由C lib和STL处理。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接