Правила, определяющие порядок компилирования модулей, являются непосредственным следствием правил видимости и, в частности, того факта, что любой библиотечный модуль, упомянутый в спецификаторе контекста компилируемого модуля, видим в нем.
Компилируемый модуль должен компилироваться после всех библиотечных модулей, указанных в его спецификаторе контекста. Вторичный модуль, являющийся телом подпрограммы или пакета, должен компилироваться после соответствующего библиотечного модуля. Любой субмодуль родительского компилируемого модуля должен компилироваться после него.
Компилирование, при котором в компилируемом модуле обнаружена ошибка, считается неудавшимся и никак не влияет на программную библиотеку; то же самое относится и к перекомпиляции (никакой компилируемый модуль не может стать устаревшим вследствие такой перекомпиляции).
Порядок компилирования компилируемых модулей программы должен отвечать частичной упорядоченности, определенной приведенными выше правилами.
Аналогичные правила применяются при перекомпиляции. На компилируемый модуль потенциально влияет изменение любого библиотечного модуля, упомянутого в его спецификаторе контекста. На вторичный модуль потенциально влияет изменение соответствующего библиотечного модуля. На субмодуль потенциально влияет изменение родительского компилируемого модуля. В результате успешной перекомпиляции компилируемого модуля все компилируемые модули, на которые потенциально влияет данный, считаются устаревшими и должны перекомпилироваться, кроме тех, которые больше не нужны. Реализация может уменьшить стоимость перекомпиляции, если установит, что данные изменения не повлияли на модули, которые находились под потенциальным влиянием данного.
Перекомпилирование субмодулей некоторого модуля на сам этот модуль никакого влияния не оказывает. Изменения в теле подпрограммы или пакета не влияют на другие компилируемые модули (кроме субмодулей этого тела), так как эти компилируемые модули имеют доступ только к спецификации подпрограммы или пакета. В реализации допустимы описанные ниже отступления от этого правила, связанные с открытыми подстановками, некоторыми оптимизациями, осуществляемыми компилятором, и некоторыми аспектами реализации настраиваемых программных модулей.
• Если прагма INLINE применяется к описанию подпрограммы в спецификации пакета, то открытая подстановка возможна, только если тело пакета откомпилировано раньше модулей, вызывающих эту подпрограмму. В таком случае открытая подстановка создает зависимость вызывающего модуля от тела пакета; компилятор должен распознавать такую зависимость при определении необходимости перекомпиляции. Если вызывающий модуль компилируется раньше, чем тело пакета, то для таких вызовов прагма INLINE может игнорироваться компилятором (при этом может быть выдано предупреждение о невозможности открытой подстановки). То же относится и к раздельно компилируемой подпрограмме, к которой применяется прагма INLINE.
• С целью оптимизации реализация может компилировать несколько модулей данной компиляции, создавая при этом дальнейшие зависимости между этими компилируемыми модулями. Эти зависимости должны учитываться компилятором для определения необходимых перекомпиляций.
• Реализация может требовать, чтобы описание настройки и соответствующее тело были частями одной и той же компиляции независимо от того, раздельно ли компилируется настраиваемый модуль или он локален в другом компилируемом модуле. Реализация может также требовать, чтобы субмодули настраиваемого модуля были частью одной и той же компиляции.
Примеры порядка компиляции:
а. В примере 1 (см. 10.1.1) процедура QUADRATIC-EQUATION должна компилироваться после библиотечных пакетов TEXT-10 и REAL-OPERATIONS, так как они упомянуты в спецификаторе совместности процедуры.
б. В примере 2 (см. 10.1.2) тело пакета STOCK должно компилироваться после соответствующей спецификации пакета.
в. В примере 2 (см. 10.1.2) спецификация пакета STOCK должна компилироваться до процедуры PROCESSOR. С другой стороны, процедура PROCESSOR может компилироваться как до, так и после тела пакета STOCK.
г. В примере 3 (см. 10.2.1) процедура G должна компилироваться после пакета TEXT-10, так как этот пакет упомянут в спецификаторе совместности процедуры G. В то же время пакет TEXT-10 может компилироваться как до, так и после процедуры ТОР.
д. В примере 3 (см. 10.2.1) субмодули TRANSFORM и FACILITY должны компилироваться после главной программы ТОР. Субмодуль G должен компилироваться после его родительского модуля FACILITY.
Примечание. Для библиотечных пакетов из правил перекомпиляции следует, что тело пакета становится устаревшим после перекомпиляции соответствующей спецификации. Если новая спецификация пакета не требует задания тела (т. е. она не содержит описаний программных модулей), то перекомпиляции тела такого пакета не требуется. В любом случае устаревшее тело пакета не должно использоваться и поэтому может быть удалено из программной библиотеки.
Ссылки: библиотечный модуль 10.1, видимость 8.3, вторичный модуль 10.1, имя 4.1, компилируемый модуль 10.1, компиляция 10.1, локальное описание 8.1, настраиваемый модуль 12, настраиваемое тело 12.2, описание настройки 12.1, описание подпрограммы 6.1, пакет 7, переменная 3.2.1, прагма INLINE 6.3.2, предвыполнение 3.9, процедура 6.1, родительский модуль 10.2, соответствующее тело 3.9, спецификатор контекста 10.1.1, спецификатор совместности 10.1.1, спецификация пакета 7.1, спецификация подпрограммы 6.1, субмодуль 10.2, тело пакета 7.1, тело подпрограммы 6.3, тело процедуры 6.3, тип 3.3.