В чем разница между компиляцией и построением в Delphi?

Ответ 1

Когда сборка, когда компилируется?

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

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

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

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

В здании есть некоторые странные случаи. Большинство результатов в "не могут найти ошибку xxx x, пока она, кажется, там

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Уточнение важности воспроизводимого выпуска

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

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