这篇文章是我几年前就想坐下来写的。我最早在 90 年代末开始开发软件，并购买了一个 Borland C++ 编译器，我很快意识到它实际上只能在 Windows 上运行。起初我做了一些小型命令行应用程序，然后开始尝试图形应用程序。我喜欢创作过程，但对许多工具感到失望。当时，我并没有真正超越改编简单的例子。
不久之后，我对开发 Web 应用程序产生了兴趣，并且在对 Perl 不满意之后，开始尝试一种名为 PHP 的新语言。我喜欢我可以相当自由地混合代码和 HTML，并且可以从 PHP 语言完全访问服务器机器。我用 PHP 开发了一些网站，并尝试了各种方法，尽可能将一些处理推送到 JavaScript。这一切都还处于初期阶段，但将其与数据库结合使用让我完成了很多工作。我还开始参与邮件列表，回答问题，并尽可能多地了解这种开源语言是如何开发的。
在那之后，我作为一名 Gentoo 开发者，对 Linux、打包应用程序以及移植到新的 64 位架构上有点分心。那非常有趣，我学到了很多关于依赖项、安全更新、共享库以及许多科学家在编写构建系统方面有多糟糕的知识。在这段时间里，我还了解了成为扩展在线社区的一部分，并且有机会与许多非常敬业和技术娴熟的人一起工作。
C++ 和原生开发
最终，我意识到我想开发软件，而且我真的想用一种可以访问硬件的本机语言进行开发。当时我使用 Linux 作为我的主要操作系统，但也经常与使用 Windows 和 Mac OS X 的人一起工作。我希望他们能够使用我开发的软件，并且不想写三遍。 正是在这个时候，我开始专注于一个软件堆栈，这在很大程度上受到了 KDE 以及我有机会与他们一起做一个 Google Summer of Code 项目 的影响。自从我做那个 Google Summer of Code 项目以来，已经大约九年了，我主要使用相同的堆栈，并进行了一些添加/更新，以促进协作、开源、跨平台开发。
C++ 是一种标准化的语言，它有许多强大的开源编译器和许多专有编译器，这些编译器涵盖了从嵌入式系统到地球上最大的超级计算机的一切。在我的工作中，我们经常以频谱的两端为目标，并在桌面/笔记本电脑领域做了大量工作。我认为它仍然是最通用的语言之一，它比 C 具有更高级别的抽象，但又足够接近底层金属以获得出色的性能。它还可以访问许多通常通过 C 接口公开的 API，甚至可以在适当的强制下与 FORTRAN 交互。
跨平台抽象
C++ 可以以可移植的方式编写，但存在许多特定于平台的 API、工具包和语言扩展。构建 C++ 应用程序也有许多方法。我从简单的手写 Makefile 开始，但很快就显而易见，即使对于简单的项目，维护这些 Makefile 也是乏味且容易出错的。我开始研究 Autotools，然后是 SCONS，之后才接触到 CMake，当时 KDE 正在考虑进行切换。
CMake 是一个元构建系统生成器，这意味着它本身不直接构建任何东西。您可以使用 CMake 语言来指定应该如何构建您的项目，并且可以在必要时为特定平台定义异常。这听起来可能也有点乏味，而且确实如此，但您会得到非常巨大的回报——它将为您的环境生成一个构建系统。如果您想使用 Visual Studio，请继续。如果您想要 Makefile，那就太好了。如果您喜欢新的 Ninja 系统，您可以使用它。我通常使用 Ninja，并结合名为 CodeBlocks 的东西，这让我获得了 Qt Creator 集成。
一旦您拥有可以构建的东西，您就需要考虑如何抽象窗口系统。我也在这里经历了很多抽象，包括 Java Swing、GTKMM（GTK 的 C++ 封装器）、wxWidgets，以及一些我想我可能已经忘记了的。我最终选择了 Qt，它过去有一个很大的缺点，即它是在 GPLv2 许可下，因此您的代码也必须使用 GPL，除非您支付了商业许可。它一直是双重许可的，但我从来没有真正喜欢这种方法。它比我尝试过的任何其他抽象都要好得多，对我来说感觉很实用、自然，而且它在 KDE 中拥有一个庞大的友好开源开发者社区。
我从 Qt 获得的另一个很棒的东西是原生外观和感觉。这种抽象努力使用原生小部件、文件对话框、颜色选择器等。随着工具包的发展，它被扩展以支持 Android 和 iOS，并且在诺基亚收购 Trolltech 后，它被重新许可为 LGPL。它还与 KDE e.V. 达成协议，保证它将永远免费，这为未来提供了保障。
版本控制，代码审查
我最初使用的是 CVS，我们通常在 Gentoo 和 KDE 中合并内容后进行代码审查。这效果很好，但需要有纪律的开发人员，他们会跟进提交列表上的提交消息。切换到 Subversion 后，情况仍然非常相似，但该工具感觉更易于使用，并且具有更高的原子性。
对我来说，最大的变革是转向 Git。起初，我们将其用作简单的直接替换，并且能够在推送提交之前在本地暂存提交。后来，我们开始研究更集成的代码审查，尝试了一些解决方案。有一段时间我们使用了 Gerrit，但我从来没有觉得界面足够直观，也不喜欢它专注于单个提交。
我现在的大部分工作都使用 GitHub 或 GitLab，这两者都非常关注查看包含一个或多个提交的分支的拉取/合并请求。这使我们可以将事物分成单独的提交（在有意义的地方），在开发时发布它们，并在准备好集成时请求审查。我喜欢这种粒度，我可以切换到单个提交以了解为什么进行了一组更改，或者查看分支的差异。逐行评论允许有重点的审查，而高级讨论可以在主选项卡中进行。
自动化构建和测试
跨平台开发的另一个重要方面是自动化构建和测试。这也最终涉及到构建/打包依赖项，因为我们很少编写不重用其他库的代码。这是 CMake 提供很多帮助的另一个领域，我们的实践也在不断发展。
我认为这是跨平台开发中更困难的方面之一，并且某些平台比其他平台更困难。传统方法是使用 cron 作业来自动化构建启动，并在主机上驱动仪表板脚本，这些脚本主要使用 CMake 通过 CTest 来自动化构建。它们还生成构建工件，这些工件会上传到 CDash。
许多项目都有我们称之为超级构建的东西。这些超级构建在最终构建我们感兴趣的项目之前，自动化项目依赖项的构建和暂存。它们使我们能够确保一切都使用正确的标志和正确的版本构建。在某些情况下，它们还与 CPack 交互，为不同的平台创建安装程序。CDash 将显示构建摘要、自动创建的安装程序、测试结果等。
结论
跨平台开发具有挑战性。重要的是在数小时内（或最坏情况下几天内）看到您在其他平台上所做更改的结果。一个项目需要将跨平台视为其工作流程的一部分，才能实现最佳结果。关于我们的方法，我还可以说很多，但这篇文章已经很长了。您可以使用本机代码取得出色的成果，并且科学应用程序通常有许多额外的依赖项。一旦您将超级计算机和嵌入式设备混合在一起，事情就会变得非常有趣。
评论已关闭。