开源的跨平台的建模工具_开源跨平台开发方法和工具

开源的跨平台的建模工具

这是我几年前一直想坐下来写的文章。 我最初在90年代后期开始开发软件，后来得到了Borland C ++编译器 ，我很快意识到这只在Windows上才真正起作用。 首先，我制作了一些小型命令行应用程序，然后开始尝试图形应用程序。 我喜欢创作过程，但对许多工具感到失望。 当时，我并没有真正超越简单的例子。

不久之后，我对开发Web应用程序产生了兴趣，并在对Perl不满意之后开始使用一种称为PHP的新语言。 我喜欢如何自由地混合代码和HTML，并可以从PHP语言完全访问服务器计算机。 我用PHP开发了一些网站，并尝试了各种可能的方式将某些处理推向JavaScript 。 这一切都是刚刚起步的，但是将其与数据库结合在一起使我完成了很多工作。 我还开始参加邮件列表，回答问题，并尽我所能了解这种开源语言的开发方式。

在那之后，我对Linux，打包应用程序以及作为Gentoo开发人员移植到新的64位体系结构有些分心。 那很有趣，而且我学到了很多有关依赖关系，安全更新，共享库以及许多科学家在编写构建系统方面有多糟糕的知识。 在此期间，我还了解了如何成为扩展的在线社区的一部分，并有机会与很多非常敬业和熟练的人一起工作。

C ++和本机开发

最终，我意识到我想开发软件，而且我确实真的想用可以访问硬件的母语进行开发。 当时，我使用Linux作为主要操作系统，但也经常与使用Windows和Mac OS X的人们一起工作。 我希望他们能够使用我开发的软件，并且不想编写三遍。 这是我开始在软件堆栈上进行调整的时候，很大程度上受KDE和我不得不与他们一起进行Google Summer of Code项目的机会的影响。 自从我从事Google Summer of Code项目以来已经有大约9年的时间，并且我在很大程度上使用相同的堆栈，并进行了一些增添/更新，以促进协作，开源，跨平台开发。

C ++是一种标准化语言 ，具有许多强大的开源编译器和许多专有的编译器，其涵盖从嵌入式系统到地球上最大的超级计算机的所有内容。 在我的工作中，我们经常针对频谱的极端情况以及台式机/笔记本电脑领域的大量工作。 我认为它仍然是最多样化的语言之一，具有比C高的抽象度，但与金属足够接近以获得出色的性能。 它还可以访问许多通常通过C接口公开的API，并且在适当强制的情况下甚至可以与FORTRAN进行交互。

跨平台抽象

C ++可以以可移植的方式编写，但是有许多特定于平台的API，工具箱和语言扩展。 还有许多方法可以构建C ++应用程序。 我从简单的手写Makefile开始，但是很快变得很明显，即使是简单的项目，维护它们也很繁琐且容易出错。 我开始研究Autotools和后来的SCONS ，然后在KDE正在考虑进行切换的那段时间里碰到CMake。

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 eV达成了一项协议，以确保它始终是免费的，从而为将来提供了保护。

版本控制，代码审查

我从CVS开始，通常在Gentoo和KDE中合并之后，我们通常会进行代码审查。 这工作得很好，但是要求纪律严明的开发人员必须遵守提交列表上的提交消息。 切换到Subversion的过程仍然非常相似，但是该工具更易于使用并且原子性更高。

对我来说，重大革命正在转移到Git上 。 最初，我们将其用作简单的直接替换，并具有在推送之前本地暂存提交的功能。 后来，我们开始研究更多的集成代码审查，尝试一些解决方案。 一段时间以来 ，我们使用Gerrit ，但我从未感到界面不够直观，也不喜欢将重点放在单个提交上。

我现在的大部分工作都使用GitHub或GitLab ，它们都非常注重于拉/合并请求，这些请求将查看包含一个或多个提交的分支。 这样一来，我们就可以将事情分成有意义的单独提交，在开发过程中将其发布，并在准备好进行集成时请求审阅。 我喜欢可以切换到单个提交的粒度，以了解为什么要进行一组更改或查看分支的差异。 逐行注释允许进行集中审核，并且高级讨论可以在主选项卡中进行。

自动化的构建和测试

跨平台开发的另一个重要方面是自动化构建和测试。 由于我们很少编写不重用其他库的代码，因此这也最终导致建立/打包依赖关系。 这是CMake提供很多帮助的另一个领域，我们的做法也在不断发展。

我认为这是跨平台开发中较困难的方面之一，某些平台比其他平台更难。 传统方法是使用cron作业来自动执行构建初始化，并在主机上驱动主要通过CTest使用CMake来自动执行构建的主机上的仪表板脚本。 它们还生成生成工件， 并将其上载到CDash 。

许多项目都有我们称为超级构建的东西。 在最终构建我们感兴趣的项目之前，它们可以自动进行项目依赖关系的构建和暂存。它们使我们能够确保使用正确的标志和正确的版本构建所有内容。 在某些情况下，它们还会与CPack交互以为不同平台创建安装程序。 CDash将显示构建摘要，自动创建的安装程序，测试结果等。

结论

跨平台开发具有挑战性。 重要的是要在几个小时（甚至是几天，最坏的情况）之内查看您在其他平台上所做的更改的结果。 为了获得最佳结果，项目需要将跨平台作为其工作流程的一部分。 关于我们的方法，我还有很多要说的，但是本文已经很长了。 您可以使用本机代码获得出色的结果，而科学应用程序通常还具有许多其他依赖性。 一旦将超级计算机和嵌入式设备投入使用，事情就会变得非常有趣。

翻译自: https://opensource.com/business/16/6/trials-and-tribulations-cross-platform-software-development

开源的跨平台的建模工具