makepp_build_check - Онлайн в облаке

ПРОГРАММА:

ИМЯ

makepp_build_check - Как makepp решает пересобрать файлы

ОПИСАНИЕ

A: "архитектура_независимая", E: "точное совпадение", I: "ignore_action", O: "only_action",
T: "target_newer"

Makepp хранит различную информацию о том, как тот или иной файл был собран в последний раз.
Эта информация включает команду сборки, архитектуру и подписи всех
зависимости файла. (Вся хранимая информация находится в подкаталоге .makepp of
каждый каталог.) Если какая-либо информация изменилась, makepp обычно решает
перестроить файл. Метод проверки сборки - это то, что контролирует решение makepp о перестройке.
Он решает, какую информацию смотреть, а какую игнорировать.

Makepp обычно выбирает правильный метод проверки сборки автоматически. Однако вы можете
изменить метод подписи для отдельного правила с помощью модификатора: build_check в
rule, или для всех правил в make-файле с помощью оператора build_check, или для всех
makefiles сразу с помощью параметра командной строки -m или --build-check-method.

Данные, используемые для принятия решения о перестройке или импорте репозитория или кеша сборки, хранятся в
файл внутренней информации о сборке. Вы можете отобразить его с помощью makeppinfo, mppi. Ниже каждого
метод дает пример того, как увидеть его ключи.

строить проверка методы включены in домен распределение
В настоящее время в дистрибутив входит пять методов проверки сборки:

точное совпадение
Этот метод использует даты изменения файла в качестве подписей. Он восстанавливает
цели, если не выполняются все следующие условия:

· Подпись каждой зависимости такая же, как и в последней сборке.

· Сигнатура каждой цели такая же, как и в последней сборке (т. Е. Никто
испортил цели с тех пор, как makepp их построил).

· Команда сборки не изменилась.

· Архитектура машины (или то, что Perl думает о ней) не изменилась.

"Exact_match" - это метод по умолчанию, если вы не перестраиваете Makefile (см. ниже).
Это очень надежный способ обеспечить правильную сборку, и почти всегда
ты хочешь. Однако у него есть несколько неожиданных побочных эффектов:

· Если вы компилировали с помощью традиционной программы make, а затем переключились на makepp,
все перекомпилируется при первом запуске makepp.

· Если вы повредили информацию makepp о том, что произошло в последней сборке (например,
вы удаляете подкаталог ".makepp" или не копируете его, когда копируете все
else), то запускается перестройка.

· Если вы заменяете файл более старой версией, запускается перестроение. Это
обычно то, что вы хотите, но это может быть удивительно.

· Если вы изменяете файл вне контроля makepp (например, вы запускаете
компиляции самостоятельно), то makepp в следующий раз восстановит файл. (Если
вы хотите избежать этого, проверьте параметр командной строки "--dont-build".)

· Независимые от архитектуры файлы перестраиваются при переключении на другой
архитектура. Обычно это не проблема, потому что они часто не занимают много времени.
строить. Причина, по которой все файлы помечены архитектурой, а не
просто двоичные файлы, часто даже файлы ASCII являются архитектурными
зависимый. Например, вывод программы Solaris "lex" не компилируется на
Linux (или, по крайней мере, это было правдой в последний раз, когда я его пробовал).

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

mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_ {DEP, VAL} S 'файл

архитектура_независимая
Метод «архитектура_независимый» аналогичен методу «точное_подключение» за исключением того, что он
не проверяйте архитектуру. Это может быть полезно для файлов, не зависящих от архитектуры,
которые не нужно перестраивать при переходе на другую архитектуру. Для
Например, вам, вероятно, не нужно повторно запускать "bison" на Solaris, если вы уже запускали его на
Linux.

Метод "architecture_independent" лучше всего использовать, указав его с помощью
модификатор ": build_check architecture_independent" для каждого правила, которое производит
независимые от архитектуры файлы. Makepp по умолчанию никогда не предполагает, что какие-либо файлы
независимая от архитектуры, потому что даже .c файлы могут зависеть от архитектуры. Для
Например, вывод Solaris lex не будет компилироваться под Linux, или, по крайней мере, он
в последний раз не пробовал. Таким образом, вы должны вручную указать этот метод проверки сборки для
любые файлы, которые действительно независимы от архитектуры.

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

mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_ {DEP, VAL} S 'файл

ignore_action
Метод "ignore_action" такой же, как и "exact_match", за исключением того, что он не проверяет
строка действия (команда). Иногда команда может измениться, а вы не хотите
принудительно перестроить.

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

BUILD_DATE: = $ (дата оболочки)

my_program: $ (МОДУЛИ) .o
$ (CXX) $ (входы) -DBUILD_DATE = "\" $ (BUILD_DATE) \ "" date_stamp.c -o $ (вывод)

Это скомпилирует date_stamp.c с последней отметкой даты сборки, но не заставит
перекомпилировать при изменении даты. К сожалению, если что-то еще о ссылке
изменения команды (например, вы меняете параметры компоновщика), это также не вызовет перестройку.

Это также полезно в сочетании с $ (changed_inputs) или $? переменная для
действия, которые просто обновляют цель, а не восстанавливают ее с нуля. Для
Например, вы можете обновить файл .a следующим образом:

libmine.a: * .o: build_check ignore_action
$ (AR) ru $ (вывод) $ (измененные_входы)

Это по-прежнему будет работать, если вы забудете указать ": build_check"
ignore_action ". Однако предположим, что ни один из файлов .o не изменился. Команда
теперь будет "ar ru libmine.a", который, вероятно, отличается от того, что было в прошлый раз
(например, "ar ru libmine.a buggy_module.o"), поэтому makepp выполнит команду. В этом
В этом случае команда не будет делать ничего, кроме пустой траты времени.

Создание таких файлов .a не рекомендуется, потому что они могут оставить устаревшие файлы .o внутри.
архив. Если вы удалите исходный файл, файл .o все еще будет внутри файла .a,
и это может привести к неправильной сборке. Лучше создать файл .a следующим образом:

libmine.a: * .o
& rm $ (вывод)
$ (AR) ru $ (выход) $ (входы)

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

mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_ {DEP, VAL} S 'файл

target_newer
Метод target_newer смотрит только на дату файла. Если какая-либо зависимость больше
позже, чем цель, цель перестраивается. Это алгоритм, который
традиционный Unix сделать утилита использует.

Метод "target_newer" не так безопасен, как метод "exact_match", потому что он не
вызвать перестройку, если вы измените команду сборки или замените файл на
старая версия. Иногда также можно запутаться, если часы не правильно
синхронизировано. Например, если файл каким-то образом получает дату 4 июня 2048 года, тогда
с настоящего момента до 2048 года каждый файл, который зависит от этого файла, будет перестроен, даже если
файл не меняется. Также переключение на другую архитектуру не вызовет
перестроить. Это предотвращает выборку цели правила из кеша сборки, потому что нет
уникальная подпись, которая может быть связана с бесконечным набором пар, выполняющих
отношения новее, чем.

Но есть несколько случаев, когда вы можете захотеть использовать метод "target_newer":

· Когда для пользователя разумно создать файл вне контроля makepp.
Возможно, наиболее распространенным примером являются команды, которые генерируют make-файл.
сама, то есть процедура автоконфигурации. Пользователи обычно выдают команду configure
команда вручную, но у make-файлов часто есть способ обновить себя
автоматически. В этом случае мы не хотим заставлять make-файл перестраивать
сам, если пользователь ввел команду вручную, поэтому метод "target_newer"
более уместен, чем метод «точное_ совпадение». Фактически, если makepp пытается
построить make-файл, он делает "target_newer" методом по умолчанию, пока он не завершится.
сборка make-файла.

· Когда пользователю разумно изменить файл после того, как makepp построил его. Для
Например, если файл не существует, вы можете скопировать его из центрального
местоположение или получить его из репозитория; но пользователю должно быть разрешено
изменить его. Если вы используете метод проверки сборки по умолчанию "exact_match", makepp будет
обнаруживает, что пользователь изменил файл, и поэтому принудительно создаст новую копию из
центральное расположение или новая касса, стирающая изменения пользователя.

Если вам нужно вручную проверить временные метки, см. Примеры makeppinfo, чтобы узнать, как получить
путь каждой зависимости.

только_действие
Очень специфический метод only_action будет выполнять действие только в том случае, если команда
строка отличается от последней. Например,

$ (КОРЕНЬ) / включить /%. H:% .h
& ln -fr $ (ввод) $ (вывод)

публикует файл, но не повторяет это при изменении файла. Обратите внимание, что & ln
команда является встроенной и, следовательно, дешевой, но makepp все равно должен отключаться и контролировать
процесс для выполнения всего действия. Итак, если у вас есть много файлов для публикации,
по-прежнему является преимуществом. На самом деле мы не указали метод, потому что, когда цель
является символической ссылкой, эта проверка сборки используется автоматически. Вам нужно только
укажите его для других команд, которые зависят исключительно от команды (которая обычно
содержит названия входов):

% .list:% .x: build_check only_action
& echo $ (входы) -o $ (выход)

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

mppi -k КОМАНДНЫЙ файл

Возможны другие методы проверки сборки. Вы можете написать свой собственный метод проверки сборки с помощью
создание модуля «Mpp :: BuildCheck :: MyMethod». Прочтите документацию в
Mpp / BuildCheck.pm в дистрибутиве makepp. Скорее всего, вам понадобится проверка сборки
метод, унаследованный от "Mpp :: BuildCheck :: exact_match", так что прочтите также его документацию.

Чаще всего полезно изменять механизм подписи, чем изменять проверку сборки.
механизм напрямую. Прежде чем менять механизм проверки сборки, посмотрите, не в чем проблема.
лучше обслуживается изменением подписей (подробности см. в makepp_signatures).

Вот несколько причин, по которым может быть полезен специальный метод проверки сборки:

· Если вы хотите, чтобы makepp игнорировал часть команды. Например, если у вас есть команды
в вашем make-файле вот так:

xo: xc
ssh $ (REMOTE_MACHINE) cc $ <-o $ @

вы можете захотеть, чтобы makepp не принудительно перестраивал, если "$ (REMOTE_MACHINE)" изменяется. Ты
может модифицировать метод «Exact_match», чтобы он знал о командах ssh и игнорировал
имя машины. Проверьте: отправьте другой способ добиться этого.

Используйте makepp_build_check в Интернете с помощью сервисов onworks.net