Why are my units "compiled with a different version" of my own files?

Question

I'm building a program that uses plugins. Unfortunately, the plugin framework's dynamic linking forces the RTL and VCL out of my project EXE and into the BPL versions, and they don't have debug info enabled.

So I built a testing framework that links to my plugins statically so I can actually see what I'm doing while tracing through the code. But now, every time I try to recompile, I get an error: "unit turbu_skills was compiled with a different version of turbu_database.GDatabase"

I've seen this error before, but only when I've been changing things I probably shouldn't have been, like the RTL or VCL libraries. I don't understand why it's doing that with my own code. The turbu_skills and turbu_database units are both units I wrote myself. GDatabase is a global singleton variable, whose class definition I haven't changed in weeks. Any change that triggers a recompile causes this error, even if I haven't touched anything in either of the units.

Doing a full build (SHIFT-F9) causes it to compile correctly. But if I then press SPACE in a unit (any unit) and hit F9, I get the error again. What's going on and how do I stop it? This doesn't happen in the main app, only the testing framework.

EDIT: I have the source to all of my units. Deleting DCUs and similar files doesn't help. Copying the entire project to a different computer, deleting all DCUs, and building there doesn't help. There's an objective, reproducible conflict between the layout of my program and the compiler, and I want to be rid of it.

The source can be found at http://www.turbu-rpg.com/downloads/Turbu_source_setup.exe if anyone wants to test it. It requires Delphi 2009 with the JVCL already installed; the installer package will take care of the rest. Maybe having the source code available will help someone track this down. I certainly hope so, because wherever the issue is, it's beyond me. The problem can be found in testing.exe and also in turbu.exe in turbu.groupproj.

EDIT 2: Turns out this was another cross-unit generics issue. Grr. I managed to code a workaround. I just hope they get the generics problems fixed soon.

Answer 1

The error "unit is compiled with a different version of..." is an annoying one. It occurs in a situation like below:

     +--------+
     | unit A |
     +--------+
      |      |
      |      |
      V      |
  +--------+ |
  | unit B | |
  +--------+ |
      |      |
      |      |
      V      V
     +--------+
     | unit C |
     +--------+

Both unit A and B use unit C and unit B uses C. Unit B and C are compiled and for some reason the source of unit B is not available. Now Unit C is changed (any change will do and is recompiled) And the dcu of unit C differs from the unit C used by unit B, so unit B needs to be recompiled too. But unfortunately, the source is not available so the compiler gives up.

It is not entirely clear what's wrong with your situation.

You have a test framework that links to the plugins. So where do unit X and Y fit in and do you recognize the pattern shown above?

But the fact that a complete build solves the problem is hint in this direction. And this is not the first time I saw problems with partial recompiles. So I always use the complete version.

Answer 2

Check that you don't have an strained old dcu file somewhere in source dir.

Answer 3

I hate this problem. I find it pops up every now and then and although it sounds in your case to be directly related to what you are doing with plugins, I've solved this in the past by finding and deleting all the dcus, bpls and dcps of the packages that we've written and then rebuilding the packages.

Answer 4

Are you using a modified VCL? The units you reference in your interface section also determine your interface. I would suggest making sure you do not have two different versions of any of your units with the same name (including VCL/RTL) that may be referenced from your project. Maybe it is something a silly as the background compilation is using a different version of the units then the disk compilation. So editing it triggers the background compiler, which then messes up the synchronization.

Answer 5

1. Your actual DPR file contains a reference to an incorrect version of a .pas file

View | Project Manager ... expand tree ... examine the path of all the units

1. There is a duplicate file in the list of search paths, and the incorrect version is found first

Answer 6

For future reference, simply pointing the compiler to source-code versions of the "problem units" fixed this for me (i.e. adding the folders containing the source code to the search path).

Answer 7

Definitely something buggy with the compiler. I have found that altering the order of the units in the uses clause will allow you to get "one free compilation" in. After that, the error re-occurs and your back to rebuilding. :-(