[参考译文] CCS/PROCESSOR-SDK-AM335X：即使排除了*。S 文件、CCS/GNU 也会编译这些文件

admin

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

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/956849/ccs-processor-sdk-am335x-ccs-gnu-compiles-s-files-even-when-excluded

器件型号：PROCESSOR-SDK-AM335X

工具/软件：Code Composer Studio

你好。

我对这种环境的不满每天都在增长...

CCS 7.2和 CCS 10都存在此缺陷。

我在同一文件夹中有一个包含*。c 文件和*。S 文件的大型项目。

我右键单击*。c 文件并单击"Build selected file"... 它编译*。S 文件(！！！)
我右键单击*。S 文件并选择"从编译中排除"。然后右键单击*。c 文件进行编译、它仍然编译*。S 文件

嗯、我没有在全球论坛上发布一个由公司所有的大型项目... 因此、我将把它拉到一个小示例项目中、以便我可以发布它。

我右键单击*。c 文件... 就像上面所做的那样编译*。S 文件
我右键单击*。S 文件并选择"从编译中排除"。然后右键单击*。c 文件、现在它不会构建*。S 文件

那么、首先、为什么、像第1步一样、当我让它构建*。C 文件时、它会构建*。S 文件？ 我可以看到 IDE 正在"Console"终端中为*。S 文件调用编译器。

第二、为什么在创建静态库的两个几乎相同的项目中、第一个项目在被告知不生成*。S 文件时会继续生成、而第二个项目会将其排除在外？

这至少耗时两天、直到我发现此缺陷...

我仍然找不到任何理由区分项目中的每个步骤2。

5 年多前

0 admin 5 年多前

TI__Guru**** 2952510 points

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

我能够使用 Windows“Xbox 游戏栏”录制屏幕。但它不显示右键单击上下文菜单。

CCS 被排除在第一个汇编器文件之外。但是、当我排除第二个文件时、它仍然会编译它。

如该视频剪辑所示。

www.youtube.com/watch

尽管上下文菜单未显示、但从突出显示的文件中可以明显看出所发生的情况。

0 admin 5 年多前

TI__Guru**** 2952510 points

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

您好、Christopher、

感谢您发布视频。看到问题非常有帮助。

在视频中、*。c 和*。S 文件具有相同的名称(当然不包括文件扩展名)。这不受支持、会导致编译出现各种问题、因为这两个文件都会导致编译后生成同名的目标文件( .o)。您是否仅在文件名相同(不包括文件扩展名)时才会看到问题？

谢谢

0 admin 5 年多前

TI__Guru**** 2952510 points

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

Ki、

我发现此问题的整个软件包是一个 WolfSSL、其中包含*。C 和*。S 文件。

我假设这与同名相关、但我没有测试。将这个小测试项目组合在一起大约需要5分钟。代码无关紧要。这正是编译器的反应方式 (源文件具有相同的函数、因此永远不会链接)

这因以下因素而变得极其复杂：

事实上、它们有"#includes"拖动到汇编器文件中的 XDC 代码中(只有#ifdefs 部分保护...)
事实上、这些 include 在 TI 编译器构建路径中几乎为空、但在 GNU 编译器中加载了代码。

因此、TI 的构建是完美的。然后、GNU 编译生成了数百个错误、所有这些错误都包含在 XDC 代码中、所有错误都从窗口中滚出、我甚至看不到原始命令行、因此不知道编译中的1000个文件中的哪一个导致了错误。

有一次我重命名了文件(我认为它没有执行"清理")、IDE 抱怨说"找不到文件 xxx.S、它是 xxx.c 的依赖项..."。我不知道为什么它得出这样的结论。

我可以看到具有相同名称的 C 代码和汇编器代码(不是在这里、而是在将来)的需求/值。我可以尝试解决这个问题、但因为它只针对"某些"文件执行此操作、所以很难预测它的行为。

e2e.ti.com/.../DummyProject.zip

0 admin 5 年多前

TI__Guru**** 2952510 points

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

谢谢。问题看起来是由于 c 和 S 文件之间的文件名相同。由于当您尝试编译 a_Source.c 或 a_Source.S 时、调用的命令是相同的：

gmake"-k -j 8 Test/a_Source.o -O

看起来构建系统会获取它找到的第一个 A_Source.*源文件。在这种情况下、它始终会抓取 A_Source.S

当我重命名 S 文件以使其具有与 C 文件不同的名称时、不会出现问题。

AFAIK、具有相同的 C 语言和汇编文件的文件名不是任何构建系统通常支持的东西。但是、最好是 CCS 在出现这种情况时向用户发出警告、以避免混淆。

0 admin 5 年多前

TI__Guru**** 2952510 points

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

好的、但是我应该能够"从编译中排除"任何文件、而不是决定是否要编译它。

正如您所说、相同的名称将生成相同的目标文件、这会导致问题。

但无法排除该文件是一个更大的问题。

我还在 CCS 7.2中看到了这一点。我在尝试处理向 GNU7.3/BIOS_6_76/XDC_3_55/NDK 3_61的大规模迁移时、仍然在它们之间来回跳动

0 admin 5 年多前

TI__Guru**** 2952510 points

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

[引用用户="Christopher Weber"]

好的、但是我应该能够"从编译中排除"任何文件、而不是决定是否要编译它。

正如您所说、相同的名称将生成相同的目标文件、这会导致问题。

但无法排除该文件是一个更大的问题。

[/报价]

C 和 S 文件的基本文件名是固定构建系统的。我假设如果文件名不同、所有文件都按预期工作。这是我们需要改进的地方、以防范这种情况。

0 admin 5 年多前

TI__Guru**** 2952510 points

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

Ki、

我会将其标记为已解决、但如果它在被告知时不排除、则仍然是一个问题。

如果它未根据名称正确排除文件、则在其他情况下可能无法正常工作。

(如果有人尝试“命名空间”他们的文件，如 stack.network.udp.c 和 stack.network.tcp.c 中的文件，会发生什么情况... 名称比较在哪里停止？)

0 admin 5 年多前

TI__Guru**** 2952510 points

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

[引用 user="Christopher Weber">如果有人尝试“命名空间”其文件，会发生什么情况，如 stack.network.udp.c 和 stack.network.tcp.c ... 名称比较在哪里停止？

它将以实际文件扩展名(*。c)停止。因此、stack.network.udp 和 stack.network.tcp 将被识别为两个不同的文件名

Code Composer Studio™︎（参考译文帖）

Code Composer Studio™︎（参考译文帖）(Read Only)

[参考译文] CCS/PROCESSOR-SDK-AM335X：即使排除了*。S 文件、CCS/GNU 也会编译这些文件