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.

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

Solution 2

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.

Solution 3

How I solved the 'path madness' in Delphi XE7:

  Rule1: Always separate the DCU from the PAS files

  Tools -> Option -> Library path: 
                 Path to global (3rd party) libraries (DCU folder) that never change.

                    c:\Delphi\Tools\FastMM\
                    c:\MyProjects\Packages\Third party packages\$(Platform)
                    c:\MyProjects\Packages\DragDrop\$(Platform)
                    c:\MyProjects\Packages\Graphics32\$(Platform)

  Project -> Options -> Search path: 
                 Path to personal libraries, that changes often. 
                 Enter the path to the DCU folder first, then path to PAS file. 
                 This way, the compiler will use the DCU files first, instead of recomilin every time from PAS files. 
                 It will recompile anyway if you do a Build.

                    c:\MyProjects\Packages\cCommonControls\$(Platform)_$(Config)
                    c:\MyProjects\Packages\cCommonControls\

  Project -> Options -> Output directory: 
                 Leave it empty so the exe file is generated in project's folder 

  Project -> Options -> DCU output directory: 
                 Use .\$(Platform)_$(Config) in order to enforce Rule1

Solution 4

This happens to me very often when I forget to change the DPK Build control from Rebuild as needed to Explict rebuild in Options...|Description.

Solution 5

In my case, I added the locations of the "problem" units to my project's search path. As long as it could find it, it compiled. Of course, if you have several versions of the file in question, it could complicate matters...

View more solutions

Comments

[Mason Wheeler]

Well, it doesn't use any files that fit the "unit B" pattern and aren't in the DPR for the testing framework, though "unit B" may be a dependency chain of more than one file. I'll look into that.