Unit <SomeUnit> Recursively Uses Itself (but it doesn't)

I have a datamodule that's used thoughout one of our line of business apps. It's in the implementation uses clause of almost every unit in the project.

I can modify business logic and other code in the implementation section of the datamodule and compile without any issues. However, any change to the interface section of the datamodule and then compiling results in the compiler error "Unit MyDataModule recursively uses itself". A build instead of a compile makes the error go away.

This is a new one I haven't seen before. Of course, I've checked to make sure that there's no way the datamodule is recursively used, and if it were in fact, the build wouldn't change anything.

Does anyone have any ideas of how to track this down or fix it? It's really annoying to have to compile, dismiss the error dialog, and then build every time a new query or method is introduced to the datamodule.

EDIT: Addressing some of the comments below and in @Marjan's answer:

I'm not using Variants or debug dcus. I've tried a solution in one of the Google search 开发者_开发百科results that looked promising about corrupt .identcache or .local files, but that didn't pan out.

Tried @Jørn's suggestion; cleaned up all temp and compiled .dcus, did a compile, and all is well. Made a change to the interface (delared a Boolean variable in the private section of the datamodule's class declaration), and hit Ctrl+F9 to compile. Error. Did a Build, all is well. Compile then works fine. Delete the Boolean, try a compile: error.

I've got roughly 20 projects of similar size (~750K-1M LOC), none of which exhibit this behavior. I've quadruple-checked that the datamodule isn't in the interface section of any of the units in the project. The datamodule itself is not extremely large (a total of 8,345 lines from 'unit' to 'end.', including comments and blank lines). The .dfm, seen as text, is a total of 8,916 lines.

EDIT 2: I guess I'll have to accept (for now, anyway) that this is a compiler glitch. I'm going to try some rearranging of things to break out some of the functionality into a separate datamodule to see if it's a size limitation (items in the DFM, maybe) or something. Thanks for all the effort.

You are running into a compiler glitch. See LKesslers question: Why does adding Action cause Fatal Error in Delphi for (an)other situation(s) in which this occurs.

And another: http://objectmix.com/delphi/633618-option-use-debug-dcus-causes-compiler-error.html which is related to using debug dcu's.

And if you google for it ( http://www.google.com/search?q=delphi+%22recursively+uses+itself%22+compiler+error ), it seems to have been around since D4...

I guess it being a compiler glitch is no consolation, but at least you are not alone...

update

I have dug up two other links with possible information on this. However they are both on experts-exchange. I normally do not include links to experts-exchange because I do not agree with their modus operandi (asking money for access to experts). In this particular case I considered "cheating" (subscribe, get the answer, post it here and cancel my subscription) to help Ken, David and anybody else afflicted with this problem. However, it doesn't feel right plus I am not about to part with my credit card details at subscription even if I can cancel before they will start charging me.

As others may hold different views on experts-exchange and/or may be keen enough to do what I am not prepared to do, the links are: http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_10206864.html and http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23848477.html Both questions have been marked "solved" and "asker verified". Whatever that may mean.

Hit the same issue, however, my solution was very small and was able to locate the root: the unit that I was trying to add to my existing project had the same name as my project. Renamed project and that was the end of that.

Been thinking about it.
Delphi can put the DCU in a different folder than the pas file.
If the search order during compile is flaky it will find the DCU first and use the interface section from that, then find the PAS file and use the implementation there.

If you force the DCU to be in the same dir as the PAS file, does the problem go away?

It is a compiler glitch, as someone else said, but I have found it helpful to try working with your library path and your search path, and your DCU output paths inside each project you have in your group. simplify the search and library paths, and with output DCU paths, make sure for example, that each project puts its DCU files in a separate folder that is NOT in the search or library path of the other projects.

Overlapping, or complex search or library paths, and ESPECIALLY shared DCUs tends to bring on such problems.

Have you tried running Delphi with the "-nocache" command line parameter? It solved a lot of problems to me. I found this solution somewhere on the Embarcadero forums.

We had same issues. It happens randomly after modify some unrelated files.

In our case trouble was:

1. Some file (x.pas) have "commonUnit.pas" in uses part - but it doesn't need it
2. modify "commonUnit.pas" or better "SomeConsts.pas" (whitch is used by commonUnit.pas but not by x.pas)
3. compile (sometimes) failed with message "Unit commonUnit.pas Recursively Uses Itself"
4. rebuild project fixes issue

Our project environment is:

• one "Compiled" folder (included in SEARCH path at first place)
• all DCU are compiled to this folder