Почему мои модули "скомпилированы с другой версией" моих собственных файлов?

Question

Почему мои модули "скомпилированы с другой версией" моих собственных файлов?

Я строю программу, которая использует плагины. К сожалению, динамическое связывание инфраструктуры плагинов вытесняет RTL и VCL из моего EXE-файла проекта в версии BPL, и у них не включена отладочная информация.

Поэтому я построил среду тестирования, которая статически связывается с моими плагинами, чтобы я мог видеть, что я делаю, во время трассировки кода. Но теперь, каждый раз, когда я пытаюсь перекомпилировать, я получаю сообщение об ошибке: "unit turbu_skills был скомпилирован с другой версией turbu_database.GDatabase"

Я видел эту ошибку раньше, но только когда менял вещи, которых, вероятно, не должно было быть, например библиотеки RTL или VCL. Я не понимаю, почему это происходит с моим собственным кодом. Единицы turbu_skills и turbu_database - это те единицы, которые я написал сам. GDatabase - это глобальная одноэлементная переменная, определение класса которой я не менял уже несколько недель. Любое изменение, которое вызывает перекомпиляцию, вызывает эту ошибку, даже если я ничего не коснулся ни в одном из модулей.

Выполнение полной сборки (SHIFT-F9) приводит к правильной компиляции. Но если я затем нажимаю SPACE на юнит (любой юнит) и нажимаю F9, я снова получаю ошибку. Что происходит и как мне это остановить? Это не происходит в основном приложении, только в тестовой среде.

РЕДАКТИРОВАТЬ: У меня есть источник для всех моих подразделений. Удаление DCU и подобных файлов не помогает. Копирование всего проекта на другой компьютер, удаление всех DCU и сборка там не помогают. Существует объективный, воспроизводимый конфликт между макетом моей программы и компилятором, и я хочу от него избавиться.

Источник можно найти по адресу http://www.turbu-rpg.com/downloads/Turbu_source_setup.exe если кто-то захочет его протестировать. Требуется Delphi 2009 с уже установленной JVCL; Пакет установщика позаботится обо всем остальном. Возможно, наличие исходного кода поможет кому-то отследить это. Я, конечно, на это надеюсь, потому что, где бы ни была проблема, это вне меня. Проблема может быть найдена в testing.exe, а также в turbu.exe в turbu.groupproj.

РЕДАКТИРОВАТЬ 2: Оказывается, это была еще одна проблема дженериков между единицами. Grr. Мне удалось закодировать обходной путь. Я просто надеюсь, что они скоро исправят проблемы с дженериками.

13

delphi compiler-construction delphi-2009 delphi-units

Источник

user32914 09 янв '09 в 19:01

14 ответов

Другие вопросы по тегам delphi compiler-construction delphi-2009 delphi-units

user18061 09 янв '09 в 19:52 2009-01-09 19:52 · Answer 1 · 2009-01-09 19:52

Ошибка "модуль скомпилирован с другой версией..." раздражает. Это происходит в ситуации, как показано ниже:

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

Оба блока A и B используют блок C, а блок B использует C. Блок B и C компилируются, и по какой-то причине источник блока B недоступен. Теперь модуль C изменяется (любое изменение будет выполняться и перекомпилируется). И dcu модуля C отличается от модуля C, используемого модулем B, поэтому модуль B также необходимо перекомпилировать. Но, к сожалению, источник недоступен, поэтому компилятор сдается.

Не совсем понятно, что не так с вашей ситуацией.

У вас есть тестовая структура, которая ссылается на плагины. Итак, где вписываются единицы X и Y, и вы узнаете схему, показанную выше?

Но тот факт, что полная сборка решает проблему, является подсказкой в этом направлении. И это не первый раз, когда я вижу проблемы с частичной перекомпиляцией. Поэтому я всегда использую полную версию.

user26335 12 янв '09 в 00:49 2009-01-12 00:49 · Answer 2 · 2009-01-12 00:49

Я ненавижу эту проблему. Я нахожу, что это всплывает время от времени, и хотя в вашем случае звучит прямая связь с тем, что вы делаете с плагинами, в прошлом я решил эту проблему, найдя и удалив все dcus, bpls и dcps из пакетов. что мы написали, а затем перестраиваем пакеты.

5

Источник

user26335 12 янв '09 в 00:49

user46207 19 окт '15 в 18:54 2015-10-19 18:54 · Answer 3 · 2015-10-19 18:54

Как я решил "путь безумия" в 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

user404981 02 сен '13 в 21:35 2013-09-02 21:35 · Answer 4 · 2013-09-02 21:35

Это случается со мной очень часто, когда я забываю изменить элемент управления DPK Build с Rebuild по мере необходимости, чтобы Explict rebuild в Options... | Description.

3

Источник

user404981 02 сен '13 в 21:35

user2740853 02 сен '13 в 19:04 2013-09-02 19:04 · Answer 5 · 2013-09-02 19:04

Модуль ppParameter был скомпилирован с другой версией ppRelatv. TppRelative:

Удалите все.dcu в папке вашей программы / на вашем компьютере, затем пересоберите или пересоберите заново. Тогда ваша программа снова заработает.

1

Источник

user2740853 02 сен '13 в 19:04

user176349 21 сен '09 в 00:10 2009-09-21 00:10 · Answer 6 · 2009-09-21 00:10

Для дальнейшего использования, просто указание компилятору версий исходного кода "проблемных единиц" исправило это для меня (т.е. добавление папок, содержащих исходный код, в путь поиска).

1

Источник

user176349 21 сен '09 в 00:10

user1389 18 дек '09 в 06:29 2009-12-18 06:29 · Answer 7 · 2009-12-18 06:29

Определенно что-то глючит с компилятором. Я обнаружил, что изменение порядка модулей в предложении использования позволит вам получить "одну бесплатную компиляцию". После этого ошибка повторяется, и вы снова перестраиваетесь.:-(

1

Источник

user1389 18 дек '09 в 06:29

user39233 10 янв '09 в 11:06 2009-01-10 11:06 · Answer 8 · 2009-01-10 11:06

Убедитесь, что у вас нет старого файла dcu в исходном каталоге.

1

Источник

user39233 10 янв '09 в 11:06

28 май '09 в 00:13 2009-05-28 00:13 · Answer 9 · 2009-05-28 00:13

Фактический файл.dpr содержит ссылку на неверную версию файла.pas.
Вид> Диспетчер проектов> разверните дерево и изучите путь всех подразделений.
В списке путей поиска есть повторяющийся файл, и в первую очередь обнаруживается неверная версия.

1

Источник

28 май '09 в 00:13

user875317 02 фев '12 в 21:08 2012-02-02 21:08 · Answer 10 · 2012-02-02 21:08

В моем случае я добавил расположение "проблемных" блоков в путь поиска моего проекта. Пока это могло найти это, это собрано. Конечно, если у вас есть несколько версий рассматриваемого файла, это может осложнить ситуацию...

1

Источник

user875317 02 фев '12 в 21:08

user7344965 06 мар '17 в 09:21 2017-03-06 09:21 · Answer 11 · 2017-03-06 09:21

У меня только что было то же сообщение об ошибке в Delphi XE. Моя была решена после закрытия Delphi, открытия его снова и перекомпиляции моего проекта.

0

Источник

user7344965 06 мар '17 в 09:21

user1041641 13 янв '15 в 18:30 2015-01-13 18:30 · Answer 12 · 2015-01-13 18:30

Мой случай и решение:

у нас было основное приложение, которое создает исполняемый файл и
некоторые проекты плагинов, которые создают файлы DLL для этого EXE
(проекту dll также нужны некоторые исходные файлы приложений)

иногда при компиляции dll файлов возникала проблема "был скомпилирован с другой версией"

проблема была в следующем:

проект exe был настроен на создание всех его файлов dcu в отдельном каталоге: например App\DCUs
проект dll имел этот каталог DCU в пути поиска, но также и некоторые из исходных каталогов приложения: например, App\Utils, App\Core, так далее.
таким образом, когда вы компилировали проект dll, некоторые исходные файлы приложения были скомпилированы снова (теперь возможно с другой версией других зависимостей):
и у нас получилось 2 разных dcu одинаковых *.pas файл

решение простое: удалите App\DCUs каталог из пути поиска проекта DLL.

user255 12 янв '09 в 17:05 2009-01-12 17:05 · Answer 13 · 2009-01-12 17:05

Вы используете модифицированный VCL? Единицы, на которые вы ссылаетесь в разделе интерфейса, также определяют ваш интерфейс. Я бы посоветовал убедиться, что у вас нет двух разных версий ваших устройств с одинаковым именем (включая VCL/RTL), на которые можно ссылаться из вашего проекта. Может быть, это что-то глупое, так как фоновая компиляция использует другую версию модулей, чем дисковая компиляция. Поэтому его редактирование запускает фоновый компилятор, который затем портит синхронизацию.

user143474 04 янв '11 в 08:00 2011-01-04 08:00 · Answer 14 · 2011-01-04 08:00

Для меня проблема была в том, что я установил Delphi с минимально необходимыми компонентами. И когда я открыл проект, который был скомпилирован с полной установкой Delphi, это случилось со мной. Копирование файлов в папке "Source" в папке установки Delphi с другого компьютера с полной установкой Delphi решило мою проблему.