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

Question

我们有一些开发人员从事非商业性活动（阅读：只是为了好玩） 跨平台的C ++项目。我们已经确定了我们需要的所有跨平台库。但是，我们的一些开发人员更喜欢使用Microsoft Visual C ++ 2008，而其他人更喜欢在GNU / Linux上使用Emacs编写代码。我们想知道我们所有人是否有可能在同一个代码库中同时或多或少地同时从两个环境中工作。最终，我们希望项目从一开始就在两个平台上进行干净的编译。

如果无法做到这一点，我们的任何开发人员都乐意切换到其他环境。我们都定期使用Linux和Windows并同时享受这两者，所以这不是试图教育一组开发者关于另一个平台的优点的问题。这是关于我们每个人都能够在我们最喜欢的环境中发展，但仍然在一个有趣的项目上合作。

要分享的任何建议或经验吗？

Answer 1

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

这将允许您设置一个存储库，其中包含一组文本文件。然后，每个开发人员都可以运行适当的cmake脚本来为他们​​的系统构建正确的构建环境（Visual Studio 2008/2005 / GNU C ++构建脚本/等）。

这里有很多优点：

• 每个开发人员都可以使用自己的构建环境
• 可以非常干净地处理依赖关系，包括特定于平台的deps。
• 构建可能不在源头，这有助于防止意外提交不适当的文件
• 轻松迁移到新开发者。环境（即：当VS 2010发布时，一些开发人员可以通过重建他们的构建文件夹来迁移）

Answer 2

我已经完成了它并且看到它没有太多问题。

您需要尝试隔离不同平台的不同代码。此外，您还需要考虑目录结构。像

这样的东西

• project / src＆lt; - .cc和.h文件
• project / src / linux | win＆lt; - 特定于一个平台或其他
的代码
• project / linux＆lt; - 制作文件和其他项目相关的东西
• project / win＆lt; - .sln和.csproj文件

基本上，您只想清楚地了解每个系统的特定内容以及常见的内容。

此外，单元测试将会非常重要，因为可能会有轻微的差异，并且您希望让Windows人员轻松运行一些测试以确保Linux代码按预期工作而另一种方式。

Answer 3

如前所述，Qt是一种非常简单的方法，可以实现真正的同步多平台开发 - 独立于您的IDE和许多不同的编译器（甚至包括Symbian，ARM，Windows CE / Mobile ......）。 / p>

在我上一家和现在的公司，我在混合的Linux和Windows开发团队工作，他们使用Subversion和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

最诚挚的问候， 克里斯

Answer 4

我有在Acronis工作的经验。我们使用相同的代码库来构建二进制文件（实际上是完全打包的安装程序），目标是Win32 / 64，Linux和OS X（以及一些其他更具异国情调的平台，例如EFI），每个人都在他们选择的IDE中工作。这里的技巧是避免编译器和IDE特定的解决方案，并使您的项目完全可以从干净的跨平台make文件构建。请注意，您可以很好地将任何make系统与VC ++一起使用，因此它不是问题（我们出于历史原因使用Watcom make，但我不建议使用它。）

您可以做的另一个技巧是添加一个make脚本，该脚本可以自动生成makefile中输入列表中的项目文件，适用于您使用的所有IDE（例如VS和Eclipse CDT）。这样，每个开发人员都会为自己生成这些东西，然后在IDE中打开这些项目进行编辑/构建/调试，但源存储库中只包含makefile。

确保代码可以编译为每个人都可能是一个问题，主要是因为VC ++在应用规则时通常比g ++更松懈（例如，它会让你将rvalue绑定到非const引用，尽管有一个警告）。如果使用处理警告编译为错误和最高警告级别（可能禁用了一些精心挑选的警告），您将主要避免这种情况。建立连续的滚动构建是另一种早期捕获方法。我们在Acronis中使用的另一种方法是让Windows构建环境中包含基于Cygwin的交叉编译工具，因此任何Windows开发人员都可以从他的框中进行针对Linux（具有相同的g ++版本和所有版本）的构建，并查看是否失败，验证他的更改将以g ++编译。

Answer 5

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

Answer 6

我们正在开展跨平台项目。我们使用Emacs进行编码，使用SCons进行构建，使用Visual Studio 2008进行调试。这是我第一次使用Emacs + SCons，我必须说，一旦你弄清楚SConstruct和SConscripts是如何工作的，这非常非常好。

Answer 7

我迟到了这个问题，这里有很多好的答案，但我没有看到任何人列举我遇到的所有问题（我在C ++中的大多数工作都是并且已经交叉了 - 平台），所以：

• 跨平台编译。每个人都很清楚这一点。 CMake和SCons非常有用。
• 平台差异。这些实际上并不限于Linux v Windows。不同版本的Windows有很多微妙的问题。如果你想从Linux跳到OS X你会发现相同的。处理器架构的差异也是如此：32 V 64位通常并不重要 - 直到它确实存在并且事情非常糟糕。这是C ++程序员所面对的比大多数其他语言更多的东西，他们的实现正在努力隐藏程序员的这种东西。
• 测试所有内容。艾伦mentions unit tests但请让我强调一下。跨平台编程的真正问题不是无法编译的代码：它的代码编译得很好并且在细微的情况下做错了。单元测试比在单一平台上工作时更重要。
• 尽可能使用便携式库。做到这一点充满了微妙的陷阱。利用别人的工作比利用自己的工作更好。 Qt在这里很有用，NSPR和APR也是有用的（后两个是C，但是如果你不想直接搞乱包装，那么包装就存在了。）这些是库明确地将平台抽象作为目标，但是应该检查您使用的大多数其他库。对那些没有可移植性记录的酷库有相当的警惕。我不是说不要使用它们：先测试一下。这样做可以为您节省大量的测试工作。
• 帕维尔mentions continual integration。如果只有少数人，这可能无关紧要。但是我发现当你考虑所有操作系统，操作系统变体和处理器差异时你得到的平台数量意味着如果没有某种形式的连续构建测试周期，你将总是缺少一些边缘情况。如果你的项目比一些人考虑做得更大，那么。
• 版本控制。最明显的问题是处理换行符和文件名区分大小写，但还有其他问题。大多数着名的开源VCS都是这样做的，但值得注意的是，通常需要几年才能找到与可移植性相关的所有错误。作为一个例子，Mercurial已经将可移植性作为其卖点之一，它有一系列修复，跨越三个或四个版本，处理不常见情况下的Windows文件名。确保您可以查看其他人在早期检查的内容。
• 脚本。使用Perl / Python / Ruby（或类似的东西）来编写脚本。试图让Linux shell和Windows批处理脚本保持同步非常繁琐。

尽管如上所述：整体跨平台是相当可行的，并没有真正的理由来避免它。我的经验是，问题往往会偶尔出现问题，但是当他们这样做时，他们所花费的时间超过了相当多的时间。如果你已经编程了一段时间，虽然你不会发现那么不寻常。

Answer 8

问题不是真正编辑C ++源文件，而是构建过程本身。 VS不使用与Linux开发通常相同的Makefile架构。一个激进的建议，但两个组实际上可以使用相同的C ++ IDE和构建过程 - 有关详细信息，请参阅Code::Blocks。

Answer 9

这是可能的（我这样做是为了赚取我的每日钱:-)）。

但是你必须记住操作系统提供的库中的差异，这可能非常烦人。 两个很好的解决方案是BOOST和QT。

两者都为您提供了与C lib和STL无法处理的有用内容的平台无关功能。

Answer 10

我以两种方式做到了这一点：

1. 每个平台都有自己的构建系统。每当有人改变某些内容（添加源文件）时，他们也会调整其他平台，或者他们发送通知，而更熟悉其他平台的人会相应地调整它。
2. 使用CMake。

我不能说我真的很喜欢CMake，但是跨平台工具肯定有它的优点。

通常，使用不同的编译器从前几行编译代码总是一个好主意，因为它有助于提高代码质量。

Answer 11

对cmake的另一次投票 需要注意的一件事是，文件名是封闭的，但在Windows上不区分大小写。它们在大多数unix文件系统上都区分大小写。

这通常是#include

的问题

例如。给定一个文件FooBar.h

 #include "foobar.h" // works on Windows, fails on Linux.

Answer 12

我同意这里的所有人建议使用cmake进行C ++中的跨平台开发。这是一个很好的工具。

我建议的另一件事是使用eclipse CDT作为开发环境。它可以在任何可以运行Java gcc并统一开发环境的地方使用。

我认为那是Alan Jackson强调单元测试。为此，您需要一些跨平台单元测试库。我在post时间读过有关C ++单元测试框架的内容。这有点过时但很周到。缺少一个也适用于两个平台的是googletest。

最后，如果你想在两个平台上自动运行这些测试，cmake还有另一个名为ctest的工具，非常适合这样做。

Answer 13

查看premake ...它与CMake非常相似，但是使用lua编写。

我已经在许多开发项目中使用了它，并且发现它易于学习并集成到现有的公司和项目结构中。

试一试！

http://industriousone.com/premake