Компиляция пакета

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

Для начала рассмотрим директивы компилятора, которые могут включаться в файл пакета и файлы модулей пакета (табл. 20.4).

Таблица 20.4. Директивы компилятора пакетов

Директива

Применение

{$IMPLICITBUILD OFF}

Служит для предотвращения перекомпиляции пакета. Применяется в тех случаях, когда пакет не изменяется

{$G-} или {IMPORTEDDATA OFF}

Применяется для предотвращения размещения модуля внутри пакета. Данная директива размещается внутри модуля. Желательно, чтобы этот модуль был напрямую связан с приложением

{ $WEAKPACKAGEUNIT ON}

Когда в файле модуля встречается данная директива, компилятор опускает данный модуль из файла so и создает локальную копию модуля тогда, когда это необходимо (при вызове данного модуля из приложения или из пакета). Модуль, имеющий данную директиву, называется слабым пакетом (weakly packaged)

{ $DENYPACKAGEUNIT ON }

То же, что и { IMPORTEDDATA OFF}

{$DESIGNONLY ON}

Компилирует пакет как пакет design-time

{$RUNONLY ON}

Компилирует пакет как пакет runtime

Рассмотрим более подробно директиву {$WEAKPACKAGEUNIT}.

Слабый пакет применяется, когда пакет ссылается на отсутствующие библиотеки so. Данная директива используется очень редко. Она позволяет обрабатывать специфические ситуации. Например, есть два компонента (в разных пакетах), которые обращаются к одному и тому же интерфейсному модулю so. Если приложение будет использовать сразу оба компонента, это приведет к загрузке двух экземпляров so, при этом могут возникнуть конфликты инициализации и использования глобальных переменных.

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

Hosted by uCoz