ModusToolbox™讲堂 | 第四课开放的生态，熟悉的味道 - 谷动谷力

在前一期我们提到了ModusToolbox™对生态的理解。我们反复地提到，ModusToolbox™希望构建一个开放的应用生态。

开放的目的，是为了接纳更多的可能性，促进成果的融合。开放的本质，是为了减少ModusToolbox™和用户的重复劳动。开放的结果，则是带来了可高度自定义的开发环境。

下面我们就来深入了解下，ModusToolbox™是如何为其生态愿景而付诸努力的。

每当选用一个新的产品，这往往代表着你又要适应一遍新的开发流程，这总是让人望而却步。

用户都希望使用自己熟悉的IDE和开发流程进行工作，作为一款推崇开放和可自定义的软件产品，ModusToolbox™自然无法拒绝这个需求。

所以，是的，ModusToolbox™允许你继续使用你熟悉的IDE来进行开发。通常而言，你有如下两种方式。

在前一期我们简单介绍过Project Creator，但其实它还隐藏了一个小彩蛋：独立运行它和在Eclipse IDE中调用它时，它的运行逻辑是不同的。Project Creator在独立运行时，会开启导出到其他IDE的选项入口，以方便你在新建例程时就直接导出到一些第三方IDE中使用。

在Eclipse IDE中调用Project Creator时，它的行为如图01。可见，图中的Target IDE是灰色不可选的状态，并限定为Eclipse IDE。这个限制是自然的，因为我们是在Eclipse IDE中调用它，故它当前只应为Eclipse IDE服务。

而独立运行Project Creator时，它的行为如图02所示。此时，Target IDE的下拉框是可以选择的，这表示它可把选中的例程生成给指定IDE使用，即生成为该IDE可以打开的工程。这一设计也是自然的，因为此时的Project Creator是独立运行的，所以它并不受制于Eclipse IDE，从而可以为受支持的IDE进行工程的创建。

“IAR Embedded Workbench”和“ARM MDK”是常用的导出选项。你甚至可以选择“None / Command line”，即不导出到任何的IDE，而采用更底层的编辑和编译方式。

有用户可能会疑惑，支持导出到多种第三方的IDE，对ModusToolbox™本身有什么好处？长此以往，ModusToolbox™生态是否会被架空，用户是否会逐步抛弃ModusToolbox™？

其实不是这样的。如你所见，得益于这个良好的导出功能，Project Creator中提供的例程只需要开发一次，即可导出到多个IDE中使用。换言之，只需要一次开发，即可让ModusToolbox™中的产品立即在多个开发平台中运行，相当于让这些产品立即上线多个开发平台。

这不仅降低了用户的学习成本，对ModusToolbox™而言也降低了的开发难度、缩短了开发周期，还让友商的IDE拥有了更多的可选资源。由此可见，开放的生态，能让各方都从中获益，这可谓是开放生态设计体系的一大胜利。

从前面可知，Project Creator本身已经可以把工程导出为Visual Studio Code工程。然而，对于Visual Studio Code这类通用的轻量编辑器级IDE，其实还有更好的办法来使用它。

Visual Studio Code支持直接打开文件夹，我们可以借助这个特性，使用它来直接编辑Project Creator为Eclipse IDE生成的工程，而无需先把工程导出为Visual Studio Code工程。

如图03，这就是Visual Studio Code直接编辑ModusToolbox™的Eclipse IDE工程的演示。可以看到，目录结构都是Eclipse IDE工程的结构，但我们却是在Visual Studio Code中编辑它。

Visual Studio Code在代码编辑与审阅方面有更多的优势，可以帮助你快速编写和更改代码。但因为ModusToolbox™自带的Eclipse IDE有官方的优化和整合，所以后续的编译和烧录的部分，回到Eclipse IDE中操作则会更合适。所以将两者结合起来会产生1+1>2的效果。

这种有机结合Visual Studio Code和Eclipse IDE的开发形式，本身也是开放生态设计体系的一部分。顺从于开放性的要求，ModusToolbox™只提供工具和接口，而极少提供范式和模式。可以说，范式和模式本身，也是用户可以并必须补足的。

于是，用户的想象力和创造力，不仅可倾注在开发工作上，也可倾注在开发工具本身。这一现象拓宽了开放生态设计体系的边界和含义，是开放生态设计体系的又一大胜利。与此同时，用户对开发工具使用形式的创新，也将反哺用户的开发工作，让开发更加高效、创作更具热情。

很多读者都喜欢使用Windows系统来进行开发。诚然，Windows是一个面向GUI而生的系统，很多优秀的可视化编辑器等工具都是基于Windows提供的，所以Windows在进行可视化的代码编辑时有很多优势。

但进行一些深入的分析和调试时，命令行环境是无法避开的，准确来说，是类UNIX的命令行环境。

因为类UNIX系统的历史地位，其所奠定的范式和规范影响深远，并且嵌入式设备的开发和GNU套件生态也存在千丝万缕的关系，导致嵌入式开发或多或少会依赖类UNIX的命令行环境及GNU工具链。

这与其说是一个限制，不如说是一个优点：因为这个历史的特殊性，嵌入式设备的从业人员也必然对类UNIX的命令行环境及GNU工具链比较熟悉，所以如果能为他们提供类UNIX的操作环境，将为他们减少很多学习成本。

鉴于此，ModusToolbox™自带了一个命令行环境，名为modus-shell。modus-shell是基于Cygwin集成而来的，他在Cygwin的核心工具集之外增加了自己的工具，并重新定义了文件系统映射。

如果你听说过Cygwin，那你一定知道，Cygwin是一个在Windows平台上运行的类UNIX模拟环境，Cygwin的主要目的是通过重新编译，将POSIX系统（例如Linux、BSD，以及其它Unix系统）上的软件移植到Windows上。

关于modus-shell的更多信息，请参见ModusToolbox Tools Package User Guide。

你可以在Eclipse IDE中通过Terminal选项卡直接使用modus-shell，也可以通过开始菜单独立运行它，如图04所示。

借助modus-shell，你能在Windows平台上获得完整的类似UNIX环境的体验。它不是虚拟机，所以无需复杂的设置，你即可在Windows上同时享受到Windows本身的便利和类UNIX命令行环境的优势，在这两者之间无缝切换，摆脱虚拟机带来的复杂的隔离。相比单独使用Windows或类UNIX系统，这种将两者松散耦合的方式会更有效地帮助到用户。

看似一个简单的集成，其实背后是开放生态设计体系的再一大胜利。不信你看，你随处可见类UNIX环境的移植、GNU软件的跨平台应用，但你鲜有看到Windows环境和工具在其它操作系统上的大规模移植和应用。

顺从于开放性的要求，一个开放的生态应该是自由且可分享的，也应该能很容易被分享和传播。

“自由且可分享”是先验的，它使得用户对类UNIX环境形成粘性，进而让用户感到熟悉和放心，于是用户会要求在更多开发作业环境中获得类UNIX的体验，这包括ModusToolbox™。

“能很容易被分享和传播”则是后验的，它使得ModusToolbox™能较为容易地集成modus-shell这个类UNIX环境，从而使得ModusToolbox™能按用户熟悉的惯例提供给用户使用，哪怕是在Windows等其它操作系统。

所以，开放生态设计体系或主动或被动地促成了ModusToolbox™集成modus-shell这一结果；同时，这也是ModusToolbox™身处开放生态、服务于开放生态的体现。

开放的生态，无论是出于主观的诉求，还是客观的需要，它最终都是为了给用户“找回熟悉的味道”。

而ModusToolbox™作为开放生态理念的践行者，它正在当仁不让地付诸努力，为了给用户“找回熟悉的味道”。

当然，ModusToolbox™的这份坚持，绝不仅仅体现在文章提到的这两点。欢迎读者挖掘隐藏在ModusToolbox™当中的更多细节，也欢迎你在评论区分享你的使用体会。