查找Delphi项目中的所有编译错误 [英] Find all compilation errors in a Delphi project

问题描述

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

I am doing some refactoring of my Delphi project. I want to be able to make a change, then see all the places in the project that break due to that change. Similar to how Eclipse lists all the compile errors for a project (in Java).

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

In Delp I can make a change, then recompile my project, but the compiler stops when it finds the first Unit that does not compile. I have to fix that Unit, compile again, which will then show me the next error, etc etc.

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

I want to be able to see all the compile errors in the project at once. Then I can decide if the change is worth doing or not. For example, if the change will require hand fixing of 50 separate source files, it's not worth doing. But if it only breaks 2 files then that's an easy change to make.

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

Is there any way to do this in Delphi? Can I tell the compiler to keep going even after finding a Unit that does not compile?

我正在使用Delphi 2010

I am using Delphi 2010

推荐答案

Delphi单元作为模块化功能，在概念上与Java jar或.NET程序集处于相似的级别；它们编译为单个文件。在Java或.NET中，当引用的模块中存在编译错误时，都不能编译依赖的模块。

Delphi units, as a modularity feature, are conceptually at a similar level to Java jars or .NET assemblies; they compile to individual files. In neither Java nor .NET can you compile dependent modules when you have compile errors in a referenced module.

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

The reason they are more granular than .NET assemblies etc. owes to their history. They were designed in part around the segmented x86 architecture; the data associated with any one unit could not be any larger than 64KB. Similarly, units served as a natural division between near code and far code. If you're familiar with 16-bit x86, you'll know that pointers to far data required a value for the segment as well as the offset, while near data only needed an offset. Calling near code was also faster than calling far code. Programs were also smaller and less complex back then; the unit was a reasonable granularity of module for an entire subsystem's worth of behaviour. This is much less the case today.

这篇关于查找Delphi项目中的所有编译错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！