В чем разница между компиляцией и сборкой в ​​Delphi? - PullRequest
17 голосов
/ 13 июля 2010

В Delphi-6 есть две опции: Build и Compile.

Я знаю, что когда я запускаю программу, она компилирует только файлы, которые изменились, и использует DCU для тех, которые этого не сделали. Когда я нажимаю «build», очевидно, он перестраивает DCU.

Что меня интересует, так это то, что когда я делаю программу для выпуска (изменение настроек сборки, условных переменных и т. Д.), Я могу просто скомпилировать или мне нужно сделать полную сборку?

Что произойдет, если я не сделаю полную сборку, есть ли смысл?

Ответы [ 4 ]

25 голосов
/ 13 июля 2010

@ Daisetsu, вот разница между сборкой и компиляцией.

Сборка компилирует все используемые модули в проекте, когда доступен исходный код.

Compile компилирует только измененные использованные модули.

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

15 голосов
/ 13 июля 2010

При сборке, при компиляции?

Компилятор автоматически перекомпилирует единицы только при изменении отметки даты и времени исходных файлов .pas (1,2).

При других изменениях состояния в проекте (директивы, отладка или другие параметры компилятора и т. Д.) Компилятор не будет автоматически перекомпилироваться.Вот когда вам нужно форсировать сборку.

Вам также нужно принудительно пересобрать, когда .inc или другие включенные ($ I) файлы изменяются (3), так как их отметка даты и времени не проверяется.

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

В сборке есть несколько странных случаев.В большинстве случаев «не удается найти юнит хх» ошибка, пока она там есть

  1. единица, когда путь к блоку в проекте неверен или используетсяотносительный путь, в то время как рабочий каталог неверен.(см. Delphi отлаживает неправильный модуль )
  2. (я не совсем уверен в этом, это гипотеза) .dcu перекомпилируется из-за CRC (1), новновь скомпилированный dcu находится в другом каталоге.Это не проблема для текущей компиляции (так как правильный dcu уже загружен), но в последующей компиляции (например, в зависимом пакете) старый файл dcu снова найден, а источник не -> error. в случае сомнений всегда очищайте свои сборки сборки, рекурсивно удаляя все DCU
  3. , в котором .dpr

(1) упоминается с неверным путеми если Delphi похож на FPC, .dcu содержит CRC раздела интерфейса всех dcu, от которых он зависит.Это можно использовать для проверки необходимости дополнительной перекомпиляции.Например, из-за манипуляций с файловой системой (перемещая dcu примерно)

(2) для экспертов, посмотрите на {$ implicitbuild xx} тоже

(3) в отличие от Delphi, FPC перестраивает на.inc изменения.Проект FPC интенсивно использует файлы .inc для внутреннего использования, это изменение уже произошло до того, как появилась поддержка Delphi.В результате пакеты, которые копируют inc-файл «define» в любой каталог, не будут компилироваться с FPC, потому что они обычно немного отличаются по размеру и CRC.Indy (10) является хорошим примером этого.

3 голосов
/ 13 июля 2010

Вы всегда должны строить при изменении настроек.

Ранее скомпилированные файлы DCU могли быть скомпилированы с другими настройками, такими как определения компилятора. Что может привести к компиляции двух модулей в одном проекте с разными настройками.

2 голосов
/ 13 июля 2010

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

Разъяснение важности воспроизводимого релиза

  • При подготовке релиза у вас будет версия вашего продукта, которую будут использовать другие люди.
  • Если они сообщают о проблемах, возможно, вам придется вернуться к этой версии, чтобы протестировать и устранить проблему.
  • Если вы не выполнили полную сборку , а вместо этого использовали существующие DCU, есть шанс , что один из ваших исходных файлов не будет перекомпилирован.
  • Даже если эта возможность довольно мала, этот шанс может серьезно помешать вашей способности быстро решить проблему.
  • Эта проблема усугубляется по мере того, как система расширяется, имеет больше взаимозависимостей иесть больше версий, «поддерживаемых в дикой природе».

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

...