makepp_build_check - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

makepp_build_check -- Як makepp вирішує відновити файли

ОПИС

A: "architecture_independent", E: "точна_відповідність", I: "ігнорувати_дія", O: "only_action",
T: "target_newer"

Makepp зберігає різноманітну інформацію про те, як той чи інший файл був створений востаннє.
Ця інформація включає команду збірки, архітектуру та підписи
залежності файлу. (Вся збережена інформація знаходиться в підкаталозі .makepp of
кожного каталогу.) Якщо будь-яка з цієї інформації змінилася, makepp зазвичай вирішує це зробити
перебудувати файл. Метод перевірки збірки — це те, що контролює рішення makepp щодо перебудови.
Він вирішує, яку інформацію дивитися, а яку ігнорувати.

Makepp зазвичай автоматично вибирає правильний метод перевірки збірки. Однак ви можете
змінити метод підпису для окремого правила, використовуючи модифікатор :build_check на
правило, або для всіх правил у make-файлі за допомогою оператора build_check, або для всіх
make-файли відразу за допомогою параметра командного рядка -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 (або, принаймні, це було правдою, коли я його востаннє пробував).

Конкретно, файл не буде перебудований або може бути отриманий зі сховища чи збірки
кешу, якщо виведення наступної команди залишається незмінним, тобто збігається з підписами
залежності:

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

архітектурно_незалежний
Метод "architecture_independent" такий самий, як і "exact_match", за винятком того, що це так
не перевіряти архітектуру. Це може бути корисно для файлів, незалежних від архітектури,
які не потрібно перебудовувати, коли ви переходите на іншу архітектуру. Для
Наприклад, вам, ймовірно, не потрібно повторно запускати "bison" на Solaris, якщо ви вже запустили його
Linux

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

Конкретно, файл не буде перебудований або може бути отриманий зі сховища чи збірки
кешу, якщо виведення наступної команди залишається незмінним, тобто збігається з підписами
залежності:

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

ignore_action
Метод "ignore_action" такий самий, як і "exact_match", за винятком того, що він не перевіряє
рядок дії (команда). Іноді команда може змінитися, а ви цього не хочете
примусово відбудовувати.

Наприклад, ви можете явно вказати дату у вашій команді для журналу, коли
build було виконано, але ви не хочете примусово перебудувати щоразу, коли виконується команда
виконано. Наприклад,

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

моя_програма: $(МОДУЛІ).o
$(CXX) $(входи) -DBUILD_DATE="\"$(BUILD_DATE)\"" date_stamp.c -o $(вихід)

Це буде компілювати date_stamp.c з останнім штампом дати збірки, але не змушує a
перекомпілювати при зміні дати. На жаль, якщо щось ще про посилання
зміни команди (наприклад, ви змінюєте параметри компоновщика), вона також не ініціює перебудову.

Це також корисно в поєднанні з $(changed_inputs) або $? змінна для
дії, які просто оновлюють ціль, а не перебудовують її з нуля. Для
наприклад, ви можете оновити файл .a так:

libmine.a : *.o : build_check ignore_action
$(AR) ru $(вихід) $(changed_inputs)

Це все одно працюватиме, якщо ви забудете вказати ": 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 $(вихід) $(входи)

Конкретно, файл не буде перебудований або може бути отриманий зі сховища чи збірки
кешу, якщо виведення наступної команди залишається незмінним, тобто збігається з підписами
залежності:

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-файл
сама по собі, тобто процедура автоналаштування. Користувачі зазвичай видають конфігурацію
команду вручну, але make-файли часто мають спосіб оновлюватися самостійно
автоматично. У цьому випадку ми не хочемо змушувати make-файл перебудовуватися
сам, якщо користувач ввів команду вручну, тому метод "target_newer" є
більш відповідний, ніж метод "exact_match". Насправді, якщо makepp намагається
створити make-файл, він робить "target_newer" методом за замовчуванням, поки він не завершиться
створення make-файлу.

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

Якщо вам потрібно вручну перевірити позначки часу, перегляньте приклади makeppinfo, як їх отримати
шлях кожної залежності.

only_action
Дуже специфічний метод "only_action" виконає дію, лише якщо команда
рядок відрізняється від останнього разу його виконання. Наприклад,

$(ROOT)/include/%.h : %.h
&ln -fr $(вхід) $(вихід)

публікує файл, але не повторює його, коли файл змінюється. Зверніть увагу, що &ln
Команда вбудована і, отже, дешева, але makepp все одно має відокремитися і контролювати a
процес для виконання всієї дії. Тож якщо у вас є багато файлів для публікації, то тут
все ще є перевагою. Насправді ми не вказали метод, тому що, коли мета
є символічним посиланням, ця перевірка збірки використовується автоматично. Вам тільки потрібно
вкажіть його для інших команд, які залежать виключно від команди (яка зазвичай
містить назви вхідних даних):

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

Конкретно, файл не буде перебудований або може бути отриманий зі сховища чи збірки
кешу, якщо виведення наступної команди залишається незмінним, тобто збігається з підписами
залежності:

mppi -kCOMMAND файл

Можливі й інші методи перевірки збірки. Ви можете написати свій власний метод перевірки збірки
створення модуля «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 і ігнорував
назва машини. Перевірте :dispatch для іншого способу досягнення цього.

Використовуйте makepp_build_check онлайн за допомогою служб onworks.net