[参考译文] CCS/C2000-CGT：多个工程编译问题

[引用 USER="Shao Ma1"] subdir_rules.mk：16：警告：覆盖目标'C：/xpath/Main/CCS3.1的配方   //注意：最后一个子文件夹名"CCS3.1"被部分截断，因为 它应该是"CCS3.1 xyz"作为完整的。

目录/路径名称中的空格已知会导致构建问题。 您的 CCSv10工作区和项目路径是什么？ 如果工程包含空格、我建议将工程导入到不包含空格的工作区路径中。  

如果问题仍未解决、请与我们分享您的项目、以便我们重现并调查错误。 如果您不想在此处发布项目、您可以通过私人邮件与我共享。 要向我发送私人消息、请将鼠标悬停在我的 E2E 论坛 ID 上并选择"发送私人消息"。 您可以压缩项目文件夹并将 zip 文件附加到消息中。

我还看到您在迁移的同一主题上创建了另一篇 E2E 帖子： https://e2e.ti.com/support/tools/ccs/f/81/t/917943 
由于这只是同一个问题的更新、我要求我们继续在该主题中进行讨论、以便可以在单个位置跟踪该问题。谢谢！

似乎 在导入 CCS 3.x 工程开始时、CCS10将使用 源 XP 工程路径进行此导入和转换、甚至会  在转换开始之前自动将其设置为"目录指定符"。 由于此 XP 路径不是我想要的、因此在我在 "Directory Specifier (目录说明符)"中手动更正它以指向  窗口10中的正确路径后、 不知怎么说、它似乎只是在表面上进行了校正、因为 CCS 10编译仍在查看相同的未校正 XP 路径、因此导致了构建错误#1。  此外、该路径名称在文件夹名称字符串中有一个空格、因此 会因将其短语截断为"弃用语法"而导致生成错误。

供参考、我的 CCS10工作区路径与 XP 项目路径不同。 它们是否应该平等地解决这个问题？  顺便说一下、如果我需要相同的源路径和目标路径名称来解决这个问题、这种做法是非常不灵活的。

请告诉我 是否有解决此问题的方法。  提前感谢。

[引用 USER="Shao Ma1]FYI、我的 CCS10工作区路径与 XP 项目路径不同。 它们是否应该平等地解决这个问题？  BTW、如果我需要为源路径和目标路径命名相同以解决此问题、这种做法将非常不灵活。

否、CCSv10工作区路径不需要与 CCS3.x 项目路径相同。  

如果不考虑项目和导致错误的情况、仍然很难提供解决方案。 您能否通过私人消息与我共享项目？   

我了解到、根据理论上的迁移要求、CCSv10工作区不必与 CCS3.x 路径相同。 但 我 要问的是、假设 src 和目标路径仅针对此问题是相同的、编译将正确拾取.obj、因此 可以正常工作。 此外、如果我删除路径文件夹名称中的任何空间、那么我还可以在 编译期间避免这种"已弃用语法"、并且在理论上、我能够 成功编译转换后的工程。

 您可以清楚地看到 、我所做的是、在 您查看如何为 CCSv10永久解决该问题的同时、弄清如何规避该问题。 关于为调试这个问题而通过项目、我需要小心不要透露 太多的来源-我的困境。  我将设置一个与上述相同的目标文件夹、以查看我的构建是否成功 、然后我可以 使用此类 证据来证明此失败。 将会通知您。

感谢您的理解。

直到今天，我才意识到，在没有收到您的答复之后， 我  昨天下午(2：00ish)的答复实际上没有记录在这个主题中(丢失了吗？) 供参考 、我看到它进入了。 该回复以"更新"我的发现开头。

下面是有关我的设置的一些额外信息  

• Windows 10企业版64位
• CCS 10.0.0.00010
• 不 涉及特定器件/电路板或调试探针、因为这是 CCS 10从 CCS 3.3进行的源代码迁移。

让我在这里再试一下、这是我6月29日调查的一次重复更新。 我所做的 是在 XP 中的迁移源和窗口10中的目标路径之间使用相同的目录路径结构、以便我能够证明 gmake 和编译是否确实由于无法在其指定的文件夹中找到.obj 而失败。 在我使 src、目标文件夹相同后、构建工作正常。  其次、在 CCS 10.0内进行转换时、我还会删除导入的 XP 源代码中的空间。 这有助于我消除构建"弃用语法"错误。 通过这种证明、我可以指出在 CCS10.0内构建的根本原因、该构建无法解析导入的 src 以使其工作区输出文件夹等正常工作  

尽管 XP src 的这种"快乐路径"安排与 CCS10目标路径的"快乐路径"安排 可以 允许编译 正确拾取.obj、但它还指出、当 src、目标路径、在迁移期间是不匹  配的时、编译仍然能够找到.obj 并成功编译。 现在、由于这种"快乐路径"安排、出现了另一个问题、导致了以下解除屏蔽：

subdir_rules.mk：9：目标配方'…。 '由于致命错误#1965而失败：无法打开源文件"std.h"

这个"std.h"是指我的旧 DSP/BIOS (5.42)所在的 include 位置。  BTW、此构建错误仅在使用其他两个较低级别的子工程编译此复合工程时发生、而在编译子工程时出现此错误。  但是、如果我独立编译同一个项目、编译就会起作用。

由于披露任何 来源的敏感性、我建议大家讨论共享屏幕的缩放、以显示足够的信息来帮助您进行调试。 请及时通知我、谢谢。  

我无法保证通过共享会话来理解和解决该问题、但我们可以先尝试一下。 TI 建议在此类调试会话中使用 WebEx。

请告诉我、下周初、您将度过一个美好的时光。 我将通过私人邮件与您联系、并提供更多详细信息。

绍

项目迁移问题(尤其是 v3.3至 v10等宽版本之间的迁移问题)并不总是非常顺利。 该工具确实会尽力尝试迁移、但有时在项目迁移后需要进行额外的手动调整。 在某些情况下(取决于项目的复杂性及其设置)、在 CCSv10中从头开始创建项目比花时间调试/修复工具迁移问题更高效。  

您是否考虑过在 CCSv10中将其创建为新项目的选项？ 在这条路径上花费的时间可能比调试3.3->10个迁移问题和等待潜在的错误修复(如果有)更有成效。 此外、如果没有可重现的测试案例、则还需要通过远程演示会话来了解问题并找到根本原因。

请告诉我您希望如何继续。