查找 Delphi 项目中的所有编译错误答案

【问题标题】：Find all compilation errors in a Delphi project查找 Delphi 项目中的所有编译错误
【发布时间】：2010-05-24 02:34:29
【问题描述】：

我正在对我的 Delphi 项目进行一些重构。我希望能够进行更改，然后查看项目中因该更改而中断的所有位置。类似于 Eclipse 如何列出项目的所有编译错误（在 Java 中）。

在 Delphi 中，我可以进行更改，然后重新编译我的项目，但编译器会在找到第一个未编译的单元时停止。我必须修复那个单元，再次编译，然后它会显示下一个错误，等等。

我希望能够一次看到所有项目中的编译错误。然后我可以决定改变是否值得做。例如，如果更改需要手动修复 50 个单独的源文件，则不值得这样做。但如果它只破坏 2 个文件，那么这很容易做出改变。

在 Delphi 中有什么方法可以做到这一点吗？即使找到无法编译的单元，我可以告诉编译器继续运行吗？

我使用的是 Delphi 2010

【问题讨论】：

标签： delphi

【解决方案1】：

Delphi 单元作为一种模块化特性，在概念上与 Java jar 或 .NET 程序集处于类似的级别；他们编译成单独的文件。在 Java 和 .NET 中，当您在引用的模块中出现编译错误时，您都不能编译依赖模块。

它们比 .NET 程序集等更精细的原因在于它们的历史。它们部分是围绕分段 x86 架构设计的；与任何一个单元关联的数据不能大于 64KB。同样，单位作为近代码和远代码之间的自然划分。如果您熟悉 16 位 x86，您就会知道指向远数据的指针需要段的值和偏移量，而近数据只需要偏移量。调用近代码也比调用远代码更快。那时的程序也更小，更不复杂。该单元是整个子系统行为价值的合理模块粒度。今天的情况要少得多。

【讨论】：

有趣。换句话说，如果我将所有课程都放在一个大单元中，而不是将每个课程放在一个单独的单元中，我可以一次看到单元中的所有错误。正如您所暗示的，这对于我们今天所做的项目规模来说并不实用（曾经有过吗？）。我当然从未见过一个 Java jar 将其全部源代码放在一个 .java 文件中！
@awmross：很有趣，但完全是错误的。 Eclipse 可以显示所有 Java 文件中的所有错误。 Delphi 显然也可以做到这一点，至少在 implementation 部分中存在错误。即使interface 部分中的错误也不会妨碍不依赖于错误单元的单元的编译。真正的原因可能是 Delphi 开发人员没有看到这个功能足够有用。
@maaartinus - 我不认为它没有被视为有用的问题，更多的是它被视为使用少。例如任何 C# 开发人员都会告诉您，当解决方案中的一个程序集编译失败时，由于该程序集不可用，通常会导致一连串错误。因此，您从要修复的 200 多个错误开始，但如果您修复第一个编译错误，所有 200 多个错误都将得到解决。那么，这 200+ -1 个错误真正提供了什么有意义的指示？可能存在大于 1 个错误有用的情况，但很少见。
@Deltics 仅对不进行重构的人没有用处。有时我想改变一些东西，需要看看它涉及多少工作。使用一个好的编译器，我会得到从零到数百个错误。如果有数百个，那么我尝试不同的方式。如果有几个，我可以看看它们，看看它们有多难修复。是的，在 Java 中，我可能每隔一天使用一次。 +++ Eclipse 中的错误不会级联。删除一个变量会破坏使用它的方法，但仅此而已。破坏方法的用户没有显示错误，这是一件好事！

【解决方案2】：

使用 Delphi 编译器无法做到这一点，但如果您正在考虑对单元公共接口的某些部分进行重大更改，您可以使用 IDE 附带的重构工具来查找对任何内容的所有引用在你改变它之前你将要改变它，这将为你提供你正在寻找的信息。

【讨论】：

我很乐意为此使用重构工具。不幸的是，它们不能跨同一项目组中的不同项目工作。它们在同一个项目中进行重构，但其他项目中使用该单元的任何单元都不会更改。
@awmross：啊。您没有在问题中提及项目 groups。
我正在使用 D2009 并使用重构。据我所知，他们正在一个项目组中跨项目工作（当然前提是您打开了该组）。当我重命名共享单元中的类或方法时，所有项目中的所有引用都会更改。诚然，我主要使用“重命名”重构......不知道其他人。
@Marjan：我在 2006 年或 2010 年都没有让它工作。你是否将重命名的类添加到其他项目文件中？还是他们只是在这些项目的搜索路径上？ “查找参考”是否也可以跨项目工作（它不适合我）。我们将我们的“库”项目安装为设计时库。也许这就是问题所在。
嗯，是的，我确实将共享单元添加到每个使用它的项目中。我不将库路径用于“自己的”代码，仅用于第三方库。这是一些额外的工作，但它使依赖关系变得明确，并有助于避免由于隐式使用可能“旧”的 dcu 潜伏在库路径上而导致的问题。啊，当您为不同的项目使用相同的单元名称和不同的内容时，它也会有所帮助。对于共享单元使用的项目特定代码很有用。共享单元只使用“unit1”，dpr 说明是哪一个。比使用库路径更明确且不易出错。

【解决方案3】：

Delphi 编译器已经尝试尽可能多地编译。
不幸的是，很多时候，一个错误的严重程度足以阻止编译器跳过错误，因为它无法假设如果代码是可编译的，它应该是什么。

此外，编译器在遇到第一个错误后给出的错误通常是不可靠的，甚至可能在第一个错误被修复后消失。（当您输入时，所有出现和消失的红色波浪线都证明了这一点）

然而，编译器所做的是提供所有提示和警告（对于某些其他编译器，这称为错误）。

【讨论】：

考虑到其他语言可以做到这一点，我不确定这是不可能的。或许 Delphi（语言）的某些原因使得无法构建执行此操作的编译器。
Delphi 有一个单通道编译器。这就是它如此之快的原因，也是为什么有些错误只是终端的原因。正如我已经说过的，它在某些情况下可以找到不止 1 个错误。

【解决方案4】：

您可以使用 Ctrl-Shift-Enter 查看当前光标下的变量、属性、方法或 wahtever 的所有出现。有了这些信息，您就可以决定是否进行更改。

唉，在当前版本中，此功能无法正常工作。

【讨论】：