Unit <SomeUnit> 递归地使用它自己（但它没有）答案

【问题标题】：Unit <SomeUnit> Recursively Uses Itself (but it doesn't)Unit <SomeUnit> 递归地使用它自己（但它没有）
【发布时间】：2011-04-07 17:21:31
【问题描述】：

我有一个数据模块，它在我们的一个业务应用程序中使用。它在项目中几乎每个单元的 implementation uses 子句中。

我可以在数据模块的实现部分修改业务逻辑和其他代码并编译没有任何问题。但是，对数据模块的接口部分进行任何更改，然后进行编译都会导致编译器错误“Unit MyDataModule 递归使用自身”。构建而不是编译会使错误消失。

这是我以前从未见过的新产品。当然，我已经检查以确保无法递归使用数据模块，如果确实如此，则构建不会改变任何东西。

有没有人知道如何追踪或修复它？每次向数据模块引入新的查询或方法时，都必须编译、关闭错误对话框，然后再构建，这真的很烦人。

编辑：解决下面和@Marjan 的回答中的一些 cmets：

我没有使用变体或调试 dcus。我在其中一个 Google 搜索结果中尝试了一个解决方案，该结果看起来 promising 关于损坏的 .identcache 或 .local 文件，但没有成功。

尝试了@Jørn 的建议；清理了所有临时文件并编译了 .dcus，进行了编译，一切都很好。对接口进行了更改（在数据模块的类声明的私有部分中声明了一个布尔变量），然后按 Ctrl+F9 进行编译。错误。做了一个构建，一切都很好。编译然后工作正常。删除布尔值，尝试编译：错误。

我有大约 20 个类似大小的项目 (~750K-1M LOC)，没有一个项目表现出这种行为。我已经四次检查数据模块不在项目中任何单元的接口部分。数据模块本身并不是很大（从'unit'到'end.'共8345行，包括cmets和空白行）。 .dfm 被视为文本，共有 8,916 行。

编辑 2：我想我必须接受（现在，无论如何）这是一个编译器故障。我将尝试重新安排一些事情，将一些功能分解到一个单独的数据模块中，看看它是否是一个大小限制（可能是 DFM 中的项目）或其他什么。感谢所有的努力。

【问题讨论】：

为什么不每次都构建？我从不使用编译。
或创建一个新单元，将您的数据模块添加到该单元的接口使用子句中，并在几乎所有其他单元中引用该单元而不是直接在数据模块中。（只是我的头顶，所以如果我有妄想，请原谅）
@Johan，您的第二个选项没有意义，您的第一个选项证明您不是在从事大型项目。 Delphi 可能很快，但对于我的大型项目，构建时间是 15 到 30 秒。 30 秒太长了：我的眼睛已经有足够的时间转移到 Stack Overflow 上并开始回答问题了。所以 30 秒变成了 30 分钟。哎呀！
@Cosmin, @Johan：加上按 F9 启动应用程序和 IDE 编译，它不进行构建...您必须记住每次在按 F9 之前进行构建。 .
对清理搜索、库和浏览器文件夹中的临时编译文件有帮助吗？我的第一个想法是编译器试图使用一些不应该使用的编译文件。

标签： delphi delphi-2007

【解决方案1】：

您遇到了编译器故障。请参阅 LKesslers 问题：Why does adding Action cause Fatal Error in Delphi 了解发生这种情况的（另一种）情况。

另一个：http://objectmix.com/delphi/633618-option-use-debug-dcus-causes-compiler-error.html 与使用调试 dcu 相关。

如果你用谷歌搜索它（http://www.google.com/search?q=delphi+%22recursively+uses+itself%22+compiler+error），它似乎从 D4 开始就存在了......

我猜这是编译器故障并不是什么安慰，但至少你并不孤单......

更新

我已经挖掘了另外两个链接，其中包含可能的信息。但是，他们都在专家交流中。我通常不包含指向专家交流的链接，因为我不同意他们的作案方式（向专家索要钱财）。在这种特殊情况下，我考虑“作弊”（订阅、获取答案、在此处发布并取消订阅）来帮助 Ken、David 和其他任何受此问题困扰的人。但是，感觉不太对劲，而且我不会在订阅时提供我的信用卡详细信息，即使我可以在他们开始向我收费之前取消。

由于其他人可能对专家交流持有不同的观点和/或可能热衷于做我不准备做的事情，链接是：http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_10206864.html 和 http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23848477.html 这两个问题都被标记为“已解决”和“询问者已验证”。不管这意味着什么。

【讨论】：

我已经被它折磨了好几年了。
我想我当时很幸运 :-) 并且 Ken 现在是一个可重现测试用例的所有者。现在，只要他能将其缩减为可重现的 QC 报告...
我的 750kloc 项目对质量控制没有多大用处
不，不够小:-)
您的变体链接不相关。仔细阅读，您会发现问题出在错误的搜索路径配置上。

【解决方案2】：

遇到同样的问题，但是，我的解决方案非常小，并且能够找到根：我试图添加到现有项目的单元与我的项目具有相同的名称。重命名项目，就这样结束了。

【讨论】：

谢谢，但这不是这里的问题。我只有一个单位有这个问题（TDataModule），它的名字与项目中的其他任何东西都不一样。（它是整个项目中唯一一个名称以 'dm` 开头的 pas/dfm 对。）
不错，我想不通。这是一个奇怪的错误，谢谢！
我认为这是最好和最常见的答案。只需重命名 pascal 文件，使其与项目文件名不匹配。修复了我的，谢谢！

【解决方案3】：

一直在考虑。
Delphi 可以将 DCU 放在与 pas 文件不同的文件夹中。
如果编译期间的搜索顺序不稳定，它将首先找到 DCU 并使用其中的接口部分，然后找到 PAS 文件并使用那里的实现。

如果您强制 DCU 与 PAS 文件位于同一目录中，问题会消失吗？

【讨论】：

数据模块的 .DCU 与源位于同一文件夹中。（我已将 SVN 配置为在签入期间忽略 .dcu 文件。）我还提到我已经删除了整个项目的所有 .dcus 并尝试了新的编译。不过，感谢您尝试回答。我感谢您的努力。

【解决方案4】：

正如其他人所说，这是一个编译器故障，但我发现尝试使用您的库路径和搜索路径以及您组中每个项目中的 DCU 输出路径很有帮助。简化搜索和库路径，并使用输出 DCU 路径，例如确保每个项目将其 DCU 文件放在一个单独的文件夹中，该文件夹不在其他项目的搜索或库路径中。

重叠、复杂的搜索或库路径，尤其是共享的 DCU 往往会带来此类问题。

【讨论】：

谢谢。这个 dm 由我遇到问题的主应用程序和另一个应用程序使用（基本上是功能有限的主应用程序的只读版本）。他们为 DM 共享同一个文件夹。 .DCU 与 .pas/.dfm 的位置相同，并且整个驱动器上没有 .pas/.dfm/.dcu 的其他实例。除此之外，项目文件夹中没有使用任何东西。我很确定没有重叠的搜索或库路径，这两个相关项目是唯一使用 DM 的项目。我会检查 AM 中的路径问题以确保。
任何地方都没有重叠的路径。 :( 还对整个驱动器上的 .DCU 进行了另一次扫描，只是为了仔细检查。只找到了一个，并且它位于正确的位置。）再次感谢您的想法。

【解决方案5】：

你试过用“-nocache”命令行参数运行Delphi吗？它为我解决了很多问题。我在 Embarcadero 论坛的某个地方找到了这个解决方案。

【讨论】：

我的也是。感谢您的努力，@Bozzy。

【解决方案6】：

我们有同样的问题。修改一些不相关的文件后随机发生。

在我们的例子中，问题是：

某些文件 (x.pas) 在使用部分包含“commonUnit.pas” - 但它不需要它
修改“commonUnit.pas”或更好的“SomeConsts.pas”（commonUnit.pas 使用whitch，x.pas 不使用）
编译（有时）失败并显示消息“Unit commonUnit.pas Recursively Uses Itself”
重建项目修复问题

我们的项目环境是：

一个“已编译”文件夹（首先包含在 SEARCH 路径中）
所有 DCU 都编译到此文件夹中

【讨论】：

正如我所说，它是一个数据模块。它用于项目中几乎所有其他单元的implementationuses 子句（实际需要它的地方）。该错误仅在我更改数据模块本身的interface 部分时发生，而不是在我更改其他单元时发生；当我修改不相关的文件时，它确实不会发生。 dcu 文件与pas 文件位于同一文件夹中，删除每个 dcu 并进行构建并不能阻止错误再次发生；也不会将整个项目检出到新文件夹中。