• 状态 Resolved
  • 已锁定 已锁定
  • 回复 2 回复
  • 订户 1 订户
  • 视图 304 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] 什么可能导致 Makefile 生成失败？

admin
Guru**** 2589245 points
Other Parts Discussed in Thread: CC1310, CCSTUDIO

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1027414/what-might-cause-makefile-generation-to-fail

主题中讨论的其他器件：CC1310、 CCStudio

我将 rfPacketRx_CC1310_LAUNCHXL_tirtos_ccs 示例项目导入到了一个新的工作区中、进行了一些更改、然后创建了第二个编译配置(只是默认调试配置的副本)。

原始配置构建正常、但新配置根本不构建。  我发现生成的 makefile 长度为零字节。

在工作区的.metadata 文件夹中有一个.log 文件、该文件报告 Java 空指针异常和此跟踪：

com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.calculateSecondaryOutputs(GnuMakefileGenerator.java:1883)
com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.addTargets(GnuMakefileGenerator.java:1332)
com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.populateTopMakefile(GnuMakefileGenerator.java:831)
com.ti.ccstudio.project.core.internal.build.CCSMakefileGenerator.populateTopMakefile(CCSMakefileGenerator.java:453)
com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.regenerateMakefiles(GnuMakefileGenerator.java:602)
com.ti.ccstudio.project.core.internal.build.CCSMakefileGenerator.regenerateMakefiles(CCSMakefileGenerator.java:383)
com.ti.ccstudio.project.core.internal.build.CCSMakefileGenerator.regenerateMakefiles(CCSMakefileGenerator.java:369)
org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performMakefileGeneration(CommonBuilder.java:1008)

因此、似乎涉及"次级输出"。  (也许不存在？)

如果有人认识到这种情况并知道潜在原因/解决方案、请告诉我。

我怀疑将 TI-RTOS 项目合并到 rfPacketRx 项目中是相关的。

作为参考、我使用的是 CCS 10.4 (但10.3存在相同的问题)、我在两台不同的计算机上看到了这种行为、其中包含多个项目。

  • 0
    TI__Guru**** 2589245 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Malcolm、

    请关闭 CCS、然后检查您的 projectspec 文件(examples\rtos\CC1310_LAUNCHXL\drivers\rfPacketRx\tirtos\ccs\rfPacketRx_CC1310_LAUNCHXL_tirtos_ccs.projectspec)。

    检查您的新构建配置文件/构建配置文件是否与调试配置相同。

    由于您说您已经合并了 tirtos builds 项目、也许您可以在合并后进行构建测试、并检查此错误的来源？

    谢谢、

    玛丽·H.

  • 0
    TI__Guru**** 2589245 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    非常感谢您的回答、Marie。

    我不确定要在 projectspec 文件中检查什么。

    当我比较.cproject XML 文件中的原始配置节点和复制的配置节点时、我发现唯一的区别是名称属性值、正如预期的那样。  (我忽略了某些其他属性值上的数字后缀。)

    正如您所建议的、我尝试了一个干净的 rfRxPacket 导入、在合并 tirtos 项目之前和之后创建了一个新的 Build Configuration。  它们都工作正常。

    由于这涉及到我的其他更改(或更多)、我尝试撤消这些更改并找到了问题：Arm 十六进制实用程序(在工程属性、编译部分中)。

    当我禁用 Arm Hex 实用程序时、我可以创建一个新的编译配置、该配置会生成有效的 makefile。  然后、我可以在复制的配置的属性中重新启用 Arm Hex 实用程序、一切都将成功。

    我假设.hex 文件可能是栈跟踪暗示的"次要输出"(在.out ELF 文件之后)。。。