Take the 2-minute tour ×

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).

In Delphi, 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.

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.

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?

I am using Delphi 2010

share|improve this question
add comment

4 Answers

up vote 5 down vote accepted

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.

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.

share|improve this answer
Interesting. So in other words, if I had all my classes in one big Unit, instead of putting each class in a separate Unit, I could see all errors in the Unit at once. As you have hinted, this is not really practical for the size of projects we do today (was it ever?). I certainly have never seen a Java jar that had its entire source in one .java file! –  awmross May 24 '10 at 5:47
@awmross: Interesting, but plain wrong. Eclipse can show all errors in all Java files. Delphi obviously could do it too, at least as there errors in the implementation part only. Even errors in the interface part do not hinder compilation of units which don't depend on the erroneous unit. The real reason is probably that Delphi developers didn't see this feature as useful enough. –  maaartinus Nov 18 '13 at 20:02
add comment

There's no way to do that with the Delphi compiler, but if you're considering making a breaking change to some part of a unit's public interface, you can use the refactoring tools that come with the IDE to find all references to whatever it is you're about to change before you change it, which will give you the information you're looking for.

share|improve this answer
I would love to use the refactoring tools for this. Unfortunately they don't work across different Projects in the same Project Group. They refactor within the same Project, but any Units in other projects that use that Unit will not be changed. –  awmross May 24 '10 at 3:34
@awmross: Ah. You didn't mention project groups in your question. –  Mason Wheeler May 24 '10 at 3:59
I am using D2009 and using Refactorings. As far as I can tell they are working across projects in a project group (provided you have the group open of course). When I rename a class or method in a shared unit, all its references are changed in all projects. Admittedly, I mostly use the "rename" refactorings... Don't know about the others. –  Marjan Venema May 24 '10 at 9:11
@Marjan: I've never got this to work in either 2006 or 2010. Do you add the renamed classes to the other project files? Or are they just on the search path of those projects? And does "Find References" work across projects too (it doesn't for me). We have our "library" project installed as a design time library. Perhaps that is the problem. –  awmross May 24 '10 at 23:42
Uh, yes, I do add shared units to every project that uses it. I don't use the library path for "own" code, only for third party libraries. It's a bit of extra work, but it makes dependencies explicit and helps avoid problems caused by implicit use of possibly "old" dcu's lurking about on the library path. Ah, and it also helps when you have the same unit name with different content for different projects. Useful for project specific code used by a shared unit. The shared unit simply uses "unit1" and the dpr says which one. More explicit and less error prone than using the library path. –  Marjan Venema May 25 '10 at 6:55
show 1 more comment

The Delphi compiler already tries to compile as much as it can.
Unfortunately, very often, an error is critical enough to prevent the compiler to move past the error as it cannot make an assumption as to what the code should be it if were compilable.

Moreover, very often, the errors a compiler can give after the 1st error has been encountered are not reliable and may even disappear after the 1st error has been fixed. (witnessed by all the red squiggly lines appearing and disappearing when you type)

What the compiler does however is to provide all the hints and warnings (which are called errors for some other compilers).

share|improve this answer
I'm not sure this is impossible, considering other languages manage to do it. Perhaps there is something about Delphi (the language) that makes it impossible to build a compiler that does this. –  awmross May 24 '10 at 3:39
Delphi has a single pass compiler. This is why it is so fast, but also why some errors are just terminal. As I already said, it can in some cases find more than 1 error. –  François May 24 '10 at 6:13
add comment

You can use Ctrl-Shift-Enter to see all occurances of the variable, property, method or wahtever is currently under the cursor. With that information you can decide to do your changes or not.

Alas, with the current version this feature doesn't work as reliable as it should.

share|improve this answer
add comment

Your Answer


