[参考译文] MSP432E411Y-BGAEVM：将 CCS 项目提交给版本控制

您好、Jim、

TI RTOS 工程和修改后的 SDK 已被放置在主工程目录中的"lib"目录中。 现在无法使用命令行管线进行构建。 [/报价]

您是否更新了库的编译器包含路径和链接器搜索路径？

我只需将 TI_RTOS 工程添加到我的工作区即可、这没问题、但我看不到任何反映此更改的修改文件、这些文件可能已提交以修复流水线构建。 链接的资源位置似乎是工作区而不是工程的一个特性、但工程位于工作区位置内(可能是几个工程中的一个)、因此工作区当前不是存储库的一部分。 是否需要提交工作区？ 如果是这样、我仍然无法发现任何提供链接资源位置的工作区文件。

我想我在这里不太清楚。 这里的 TI_RTOS 项目是什么？ 您在谈论什么修改的文件？ 是您为 TI_RTOS 项目还是主项目修改的文件？ 您修改的哪些文件未反映出来？ 必须承认、我不是 SimpleLink 和 TI-RTOS 内部工作的专家。 一些 SDK 文件是根据用于 SL SDK 的.syscfg 和用于 TI-RTOS 的.cfg 生成的。 我不确定您修改了哪些文件。 我知道 ti_drivers_config.c 和 ti_drivers_config.h 等文件是基于.syscfg 生成的。 如果您修改这些文件、那么在您下次重建项目时这些文件将被覆盖。  

以 uartecho.syscfg 为例、如果碰巧修改这些文件、您可以扩展生成的文件、并使其不会再次生成。  

[/quote]

尊敬的 Charles：

感谢您的观看。

首先、要明确的是、我在构建我的项目时没有遇到问题、我可以这么做。 我的问题是将它承诺到 VC 以便其他人可以构建它。

关于 TI_RTOS 工程：

首次导入基于 TI RTOS 的示例(例如 tcpecho_MSP_EXP432E401Y_tirtos_ccs)时、您还会在工作区中获得第二个项目- tirtos_builds_MSP_EXP432E401Y_release_ccs。 此 TI_RTOS 工程包含 release.cfg、您可以在其中更改 RTOS 的配置(优先级数、矢量位置、启用任务标签...)。 它会构建一个 RTOS 库 sysbios.aem4f。

主工程将"tirtos_builds_MSP_EXP432E401Y_release_ccs"作为链接资源、并从该工程继承一些重要的符号、例如 SDK 位置和一些其他路径。

我们已经将 TI RTOS 项目移动到主项目内的库目录中。 只要更新工作区以在新位置包含 TI RTOS 工程、就会生成该工程。

我们还将 SDK 移到了主工程目录内的 lib 目录中。 我在 TI_RTOS 项目中设置了 SDK 的新位置-一切都构建正常。 (要执行此步骤、我在 CCS 的首选项设置下将新的 SDK 实例添加到 CCS -然后可以在 RTOS 工程的属性对话框中将新的 SDK 添加到该工程中)

问题是、对于这两项更改、我无法看到任何已更改以反映新位置的文件。 我似乎没有可以承诺更新这些新位置的更改文件。 我的构建正常、但是构建服务器失败了。

吉姆

您好、Jim、

 我不知道如何回答您的问题。 我需要将您的问题转发给我们的 CCS 专家、以获取有关工程如何/是否在工作区元数据中注册的评论。

 这是我可以看到的。 在 tcpecho_msp_EXP432E401Y_tirtos_ccs 中、有一个对 tirtos_builds_MSP_EXP432E401Y_release_ccs  的依赖项。  

在链接器库搜索路径中、有以下路径可访问 tirtos_builds_MSP_EXP432E401Y_release_ccs。  

假设在您将 tirtos_builds_MSP_EXP432E401Y_release_ccs 移动到 主项目中的子目录(如/lib)之后、您会想知道在不同的 工作区元文件之间更改了哪些元数据文件、以便可以对这些元数据进行版本控制。 这是正确的理解吗？

我会将您发表的文章转给我们的 CCS 专家以便评论。 同时,我认为有一个实验你可以做. 创建另一个包含主工程的工作区、并 以并行层次结构创建 tirtos_builds_MSP_EXP432E401Y_release_ccs  、与示例 tcpecho_MSP_EXP432E401Y_tirtos_ccs 相同。 对工作区和 CCS 元文件的两个工作区进行超越比较。 另一个工作区是将 tirtos_builds_MSP_EXP432E401Y_release_ccs 移动 到主项目下的/lib 中的工作区。 我不知道此比较是否会揭示有关 tirtos_builds_MSP_EXP432E401Y_release_ccs 的位置变化的任何内容。  

您好、Jim、

我们已将 TI RTOS 项目移至主项目内的库目录。

您是否将 TI-RTOS 项目合并到主项目中以便只使用一个 RTSC 项目？ 还是两个独立的项目、其相关 RTOS 项目文件夹只是物理移动到主项目的库目录中？

链接的资源位置似乎是工作区的一个功能，而不是项目

链接的资源路径变量和编译变量均可在工作区和工程级别设置。 如果在工作区级别设置、则该信息将存储在工作区文件夹元数据中。 请参阅以下文档的"变量"部分：

https://dev.ti.com/tirex/explore/node?node=A__APCOPn6qUQAjzKNUeB0cuQ__ccs_devtools__FUz-xrs__LATEST

第二、主工程是通过 TI_RTOS 工程导入 SDK 位置。 这是指我的硬盘驱动器上的一个旧版本，因此在构建服务器上自然无法工作。

已发现产品的信息实际上根据 CCS 安装而定。 一旦 CCS "发现"某个产品(如 SDK 或 TI-RTOS)、该信息将存储在 CCS 目录内的一个文件中、并将应用于使用同一 CCS 安装的所有工作区。 如果使用新的 CCS 安装程序、则该 CCS 安装程序需要重新查找产品。

请参阅以下文章中的"产品发现"： https://dev.ti.com/tirex/explore/node?node=A__AO8DVCZhl0Kt5-yIAVmyvQ__ccs_devtools__FUz-xrs__LATEST

希望这有助于澄清一些问题。

小

您好！

感谢您的帮助。

我还没有将 RTOS 项目合并到我的主项目中-这可能会有所帮助。 是否有任何有关如何执行该操作的信息？

我们的编译服务器专家通过将 RTOS 工程移至与主工程相同的顶层目录来实现编译-该目录作为"工作区"传递给 Eclipse 命令行编译工具、然后找到链接的资源。

他们需要的另一个技巧是在构建服务器上的 Code Composer 中安装 SDK。 不幸的是、这意味着任何克隆系统信息库 的人在构建之前也必须执行此操作-它并非全部包含在系统信息库中。 我想这与安装编译器的要求没有什么不同、但我假定项目会知道这一点！

最后一步是重命名 SDK。 我们有多个电路板使用 MSP432E401和...411、这些电路板对 SDK 需要不同的模块、因此我们需要安装几个需要不同名称的不同版本。 似乎我们可以通过调整 SDK 中的一些清单文件来实现这一点。

谢谢

吉姆

我还没有将 RTOS 项目合并到我的主项目中-这可能会有所帮助。 是否有任何有关如何执行此操作的信息？

其中涉及将主工程转换为 RTSC 工程并添加适当的文件。 这有点超出我的专业领域、我不确定这是您想要尝试的东西。

我们的构建服务器专家已设法通过将 RTOS 项目移至与主项目相同的顶层目录来构建该项目-该目录作为"workspace"传递给 Eclipse 命令行构建工具，然后它会找到链接的资源。

由于 RTOS 工程是主工程的相关工程、因此两者都需要导入到工作区中  

他们需要的另一个技巧是在构建服务器上的 Code Composer 中安装 SDK。 不幸的是、这意味着任何克隆系统信息库 的人在构建之前也必须执行此操作-它并非全部包含在系统信息库中。 我想这与要求安装编译器没有什么不同、但我假定项目会知道这一点！

是否在 CCS 内安装 SDK、以便自动发现该 SDK？ 您通常不希望将 SDK 安装在 CCS 文件夹中。