мінуси - онлайн в хмарі

ПРОГРАМА:

ІМ'Я

Мінуси - Система побудови програмного забезпечення

ОПИС

Посібник і довідник для версії 2.2.0

Авторське право (c) 1996-2000 Фонд вільного програмного забезпечення, Inc.

Ця програма є безкоштовним програмним забезпеченням; ви можете розповсюджувати його та/або змінювати відповідно до умов
Загальна публічна ліцензія GNU, видана Фондом вільного програмного забезпечення; або
версія 2 Ліцензії або (на ваш вибір) будь-яка наступна версія.

Ця програма поширюється в надії, що вона буде корисною, але БЕЗ БУДЬ-ЯКИХ ГАРАНТІЙ;
навіть без неявної гарантії про придатність до продажу або придатність для певної мети.
Докладніше див. У Загальній публічній ліцензії GNU.

Ви повинні були отримати копію Загальної публічної ліцензії GNU разом із цією програмою;
див. файл КОПІЮВАННЯ. Якщо ні, напишіть до Free Software Foundation, Inc., 59 Temple
Місце - Suite 330, Бостон, Массачусетс, 02111-1307, США.

Вступ

мінуси є системою для побудови, насамперед, програмного забезпечення, але значно відрізняється від
попередні системи конструювання програмного забезпечення. Мінуси були розроблені з нуля, щоб узгодити
легко за допомогою конструювання програмного забезпечення, розподіленого по декількох вихідних каталогах. Мінуси
дозволяє легко створювати прості, зрозумілі та підтримувані сценарії збірки.
Мінуси гарантують, що складне програмне забезпечення легко і точно відтворюється.

Cons використовує ряд прийомів для досягнення всього цього. Скрипти побудови просто
Скрипти Perl, що робить їх як легкими для сприйняття, так і дуже гнучкими. Глобальне охоплення
змінних замінено механізмом імпорту/експорту для обміну інформацією між
сценаріїв, що значно покращує читабельність і ремонтопридатність кожного сценарію.
будівництво середовищах представлені: це об’єкти Perl, які захоплюють
інформація, необхідна для контролю процесу побудови. Використовується кілька середовищ
коли для створення продуктів у дереві збірки потрібна різна семантика. Мінуси
реалізує автоматичний аналіз залежностей і використовує його для глобальної послідовності всього
будувати. Варіантні збірки легко створюються з одного вихідного дерева. Інтелектуальна конструкція
піднабір можливий при роботі над локалізованими змінами. Перевизначення можна налаштувати на
легко замінити інструкції збірки, не змінюючи жодних скриптів. MD5 криптографічний
підпису пов’язані з похідними файлами та використовуються для точного визначення чи
даний файл потрібно відновити.

Пропонуючи все вищесказане та багато іншого, мінуси залишається простим і легким у використанні. Це буде,
Сподіваюся, це стане зрозумілим, коли ви прочитаєте решту цього документа.

Чому Мінуси? Чому НЕ Зробити?

Мінуси - це а зробити заміна. У наступних параграфах ми розглянемо деякі з них
небажані характеристики make--і типові середовища побудови, засновані на make--це
мотивував розвиток Конс.

Будувати складність

Традиційні системи будь-якого розміру на основі виробників, як правило, стають досить складними. Оригінальна марка
Корисність та її похідні внесли свій внесок у цю тенденцію у ряді способів. Зробити є
не дуже добре працювати з системами, які розподілені по декількох каталогах. Різні роботи -
для подолання цієї труднощі використовуються навколо; звичайним вибором є виклик make
рекурсивно для кожного підкаталогу збірки. Це призводить до складного коду, в
часто незрозуміло, як встановлюється змінна, або який вплив це налаштування змінної
матиме на будівництві в цілому. Мова сценаріїв make поступово розширювалася
щоб надати більше можливостей, але вони значною мірою вже загромаджували
надмірно розширена мова. Часто збірки виконуються за кілька проходів, щоб забезпечити
відповідні продукти з одного каталогу в інший каталог. Це являє собою подальше
збільшення складності збірки.

Будувати відтворюваність

Прокляттям усіх марок завжди була правильна обробка залежностей. Найчастіше, an
Зроблено спробу виконати розумну роботу із залежностями в межах одного каталогу, але ні
робиться серйозна спроба виконати роботу між каталогами. Навіть коли є залежності
Працюючи правильно, make покладається на просте порівняння відмітки часу, щоб визначити чи
застарілий файл щодо його залежних осіб, загалом, не підходить для
визначення того, коли файл повинен бути повторно отриманий. Якщо, наприклад, є зовнішня бібліотека
перебудований, а потім ``встановлений'' на місце, мітки часу на його щойно створених файлах можуть
добре бути раніше, ніж останній локальний build, оскільки він був побудований до того, як він став видимим.

варіант Будує

Make надає лише обмежені можливості для обробки варіантів збірок. З розповсюдженням
апаратних платформ і потреба в налагоджуваному та оптимізованому коді, здатність до
легко створювати ці варіанти дуже важливо. Що ще важливіше, якщо будуть створені варіанти, то це
важливо мати можливість розділяти варіанти або мати можливість відтворити їх
оригінал або варіант за бажанням. За допомогою make дуже важко розділити вбудовування
кілька каталогів збірки, окремо від джерела. І якщо цю техніку не використовувати,
також практично неможливо гарантувати в будь-який момент часу, в якому варіанті присутній
дерево, не вдаючись до повної перебудови.

Сховища

Make надає лише обмежену підтримку для створення програмного забезпечення з коду, який існує в a
структура каталогів центрального сховища. Функція VPATH GNU make (та деякі інші
make реалізацій) призначений для забезпечення цього, але працює не так, як очікувалося: it
змінює шлях цільового файлу на ім’я VPATH занадто рано під час його аналізу, і тому
шукає всі залежності в каталозі VPATH. Щоб забезпечити правильний розвиток
builds, важливо мати можливість створити файл у локальному каталозі збірки та мати
будь-які файли в репозиторії коду (каталог VPATH, в термінах make), які залежать від локального
файл відновлюється належним чином. Це неможливо з VPATH, без кодування великої кількості
складні сховища знань безпосередньо в make-файли.

зберігання it простий

Деякі труднощі з make були згадані вище. У цьому та наступних
розділах, ми представимо мінуси та покажемо, як ці проблеми вирішуються.

Perl scripts

Мінуси засновано на Perl. Тобто мінуси скриптів--Призовник та Конструкція файли, еквівалент
до Makefile or makefile-- всі написані на Perl. Це забезпечує негайну вигоду:
Мова написання сценаріїв знайома. Навіть якщо ви випадково не Perl
програмісту, корисно знати, що Perl в основному є простою декларативною мовою,
з чітко визначеним потоком керування та знайомою семантикою. Він має змінні, які поводяться
в основному так, як ви очікуєте від них, підпрограми, потік керування тощо. Там
не вводиться спеціальний синтаксис для Cons. Використання Perl як мови сценаріїв
спрощує завдання висловити відповідне рішення часто складного
вимоги до споруди.

Здравствуйте, Світ!

Щоб обґрунтувати наступне обговорення, ось як ви можете створити Здравствуйте, Світ! C
додаток з мінусами:

$env = нові мінуси ();
Програма $env 'hello', 'hello.c';

Якщо ви інсталюєте цей сценарій в каталозі, надайте сценарій ім’я Конструкція, і створіть
привіт.c вихідний файл у тому самому каталозі, то ви можете ввести `cons hello', щоб створити файл
Додаток:

% мінуси привіт
cc -c привіт.c -o привіт.о
cc -o привіт hello.o

будівництво середовищах

Ключовим спрощенням мінусів є ідея a будівництво навколишнє середовище. Конструкція
середовище - це об'єкт характеризується набором пар ключ/значення та набором методи
Щоб розповісти Cons, як щось створити, ви викликаєте відповідний метод через an
відповідне будівельне середовище. Розглянемо наступний приклад:

$env = нові мінуси (
CC => 'gcc',
LIBS => 'libworld.a'
);

Програма $env 'hello', 'hello.c';

У цьому випадку замість того, щоб використовувати середовище побудови за замовчуванням, як є, ми маємо
перевизначено значення `CC', щоб замість цього використовувався еквівалент компілятора GNU C. Так як
ця версія Здравствуйте, Світ! потрібна бібліотека, libworld.a, ми вказали, що будь-який
програма, пов'язана в цьому середовищі, повинна бути пов'язана з цією бібліотекою. Якщо бібліотека
вже існує, добре і добре, але якщо ні, то нам також доведеться включити заяву:

Бібліотека $env 'libworld', 'world.c';

Тепер, якщо ви введете `cons hello', бібліотека буде створена до того, як програма буде пов’язана, і,
звичайно, `gcc' буде використовуватися для компіляції обох модулів:

% мінуси привіт
gcc -c привіт.c -o привіт.о
gcc -c світ.c -o світ.о
ar r libworld.a world.o
ar: створення libworld.a
ranlib libworld.a
gcc -o привіт привіт.o libworld.a

автоматичний та повний залежність аналіз

З мінусами залежності обробляються автоматично. Продовжуючи попередній приклад, прим
що коли ми модифікуємо world.c, world.o перекомпілюється, libworld.a відтворено, і привіт
повторно зв'язано:

% vi world.c
[EDIT]
% мінуси привіт
gcc -c світ.c -o світ.о
ar r libworld.a world.o
ar: створення libworld.a
ranlib libworld.a
gcc -o привіт привіт.o libworld.a

Це відносно простий приклад: мінуси «знає» world.o залежить від world.c, Так як
залежність явно встановлюється методом «Бібліотека». Воно також це знає libworld.a
залежить від world.o і що привіт залежить від libworld.a, все з схожих причин.

Тепер виявляється, що привіт.c також містить файл визначення інтерфейсу, world.h:

% emacs world.h
[EDIT]
% мінуси привіт
gcc -c привіт.c -o привіт.о
gcc -o привіт привіт.o libworld.a

Звідки Cons це знає привіт.c includes world.hІ що привіт.о тому має бути
перекомпільований? Поки що достатньо сказати це, коли обмірковуєш чи ні привіт.о вгору-
на сьогоднішній день Cons викликає сканер для визначення своєї залежності, привіт.c. Цей сканер перераховує
файли, включені до привіт.c щоб створити список інших залежностей, крім них
чітко визначено сценарієм Cons. Цей процес є рекурсивним: будь-які файли, включені до
включені файли також будуть скановані.

Хіба це не дорого? Відповідь - це залежить. Якщо ви робите повну збірку великої системи,
час сканування незначний. Якщо ви робите перебудову великої системи, то мінуси будуть
витратити досить багато часу на роздуми, перш ніж вирішити, що нічого не повинно бути
зроблено (хоча не обов’язково більше часу, ніж зробити!). Хороша новина полягає в тому, що у Cons це виходить
дуже легко розумно підмножити свою збірку, коли ви працюєте над локалізованими змінами.

автоматичний в цілому будувати послідовності

Тому що Cons виконує повний і точний аналіз залежностей, і робить це глобально, для
всю збірку, Cons може використовувати цю інформацію, щоб отримати повний контроль над послідовності
будови. Ця послідовність очевидна у наведених вище прикладах і еквівалентна чому
ви очікували для make, враховуючи повний набір залежностей. З мінусами це розширюється
тривіально для більших, багатокаталогових збірок. Як наслідок, пов’язана вся складність
щоб переконатися, що збірка організована правильно, включаючи багатопрохідну ієрархічну
будує - усувається. Ми обговоримо це далі в наступних розділах.

Створюємо великий дерева - ще просто as простий

A ієрархія of будувати scripts

Більша збірка, у Cons, організована шляхом створення ієрархії будувати scripts. На вершині
дерева — це сценарій під назвою Конструкція. Решта сценаріїв, за умовою, є кожен
званий Призовник. Ці сценарії дуже просто пов’язані між собою за допомогою `Build',
Команди "Експорт" та "Імпорт".

Команда Будувати команда

Команда `Build' приймає список Призовник імена файлів і влаштовує їх
включені в збірку. Наприклад:

Побудувати qw(
драйвери/дисплей/призовник
драйвери/миша/строкову службу
парсер/призовник
комунальні послуги/Призовник
);

Це проста дворівнева ієрархія сценаріїв збірки: всі дочірні компанії Призовник файли
згадуються на верхньому рівні Конструкція файл. Зверніть увагу, що не всі каталоги в дереві
обов'язково мають пов'язані з ними сценарії збірки.

Це також можна написати як багаторівневий сценарій. Наприклад, Конструкція файл міг
містить цю команду:

Побудувати qw(
парсер/призовник
водії/Призовник
комунальні послуги/Призовник
);

і Призовник файл у файлі драйвери каталог може містити це:

Побудувати qw(
дисплей/Призовник
миша/Призовник
);

Досвід показав, що колишню модель трохи легше зрозуміти, оскільки
все дерево конструкції викладено перед вами, на верхньому рівні. Гібридні схеми є
також можливо. Окремо обслуговуваний компонент, який потрібно включити в a
Наприклад, дерево побудови може підключатися до дерева побудови в одному місці, але визначати власне
будівельна ієрархія.

За замовчуванням Cons не змінює свій робочий каталог на каталог, що містить a
допоміжний Призовник файл, який він містить. Цю поведінку можна ввімкнути для збірки
вказуючи, на верхньому рівні Конструкція Файл:

Призовник_чдір 1;

Якщо ввімкнено, мінуси зміниться на дочірню компанію Призовник файл, що містить каталог
під час читання цього файлу, а потім перейдіть назад до каталогу верхнього рівня після файлу
було оброблено.

Очікується, що така поведінка стане стандартною в майбутній версії Cons.
Щоб підготуватися до цього переходу, збірки, які очікують, що мінуси залишаться у верхній частині збірки
поки він читається в дочірній компанії Призовник файл повинен явно вимкнути цю функцію як
наступним чином:

Призовник_чдір 0;

родич, найвищий родич, та абсолютний файл Імена

Можливо, ви помітили, що імена файлів, зазначені в команді Build, відносяться до
розташування сценарію, з якого він викликається. Як правило, це справедливо для інших імен файлів
аргументи до інших команд також, хоча ми могли б також згадати тут, якщо ви почнете
ім'я файлу з хешем, ``#'', потім цей файл інтерпретується відносно верхнього
каталог рівня (де Конструкція файл знаходиться). І, що не дивно, якщо почати
з ``/'', то він вважається абсолютним ім'ям шляху. Це справедливо навіть для систем
які використовують зворотну, а не пряму косу риску для назви абсолютних шляхів.

використання Модулі in будувати scripts

Ви можете затягнути модулі в кожен Призовник файл за допомогою звичайного Perl `use' або `require'
твердження:

використовувати англійську;
вимагає My::Module;

Кожне «використання» або «вимагати» впливає лише на одне Призовник файл, у якому він з'являється. Щоб використовувати a
модуль у кількох Призовник файлів, ви повинні помістити оператор `use' або `require' в кожен
той, якому потрібен модуль.

Сфера of змінні

Найвищий рівень Конструкція файл і все Призовник файли починають життя в загальному окремому Perl
пакет. мінуси керує таблицею символів для пакета, щоб таблиця символів для
кожен сценарій порожній, за винятком Конструкція файл, який отримує частину командного рядка
аргументи. Тому всі змінні, які встановлюються або використовуються, встановлюються сценарієм
сам по собі - не за якимось зовнішнім сценарієм.

Змінні можуть бути явними Імпортований за сценарієм із його батьківського сценарію. Щоб імпортувати a
змінна, вона повинна була бути експортується батьківським та ініціалізованим (інакше помилка
відбудеться).

Команда Експорт команда

Команда "Експорт" використовується, як у наступному прикладі:

$env = нові мінуси ();
$INCLUDE = "#export/include";
$LIB = "#export/lib";
Експортувати qw( env INCLUDE LIB );
Збірка qw( util/Conscript );

Значення простих змінних, згаданих у списку «Експорт», будуть вилучені
будь-якими наступними командами `Build'. Команда "Експорт" експортує лише Perl скалярний
змінні, тобто змінні, ім'я яких починається з "$". Інші змінні, об’єкти тощо.
можна експортувати за посиланням, але всі сценарії посилатимуться на той самий об’єкт, і це
Допоміжні сценарії та оригінал слід вважати об’єкт доступним лише для читання
скрипт експорту. Однак допустимо призначити нове значення експортованому скаляру
змінна - це не змінить базову змінну, на яку посилається. Ця послідовність, для
наприклад, нормально:

$env = нові мінуси ();
Експортувати qw( env INCLUDE LIB );
Збірка qw( util/Conscript );
$env = нові мінуси (CFLAGS => '-O');
Build qw( other/Conscript);

Не має значення, чи встановлюється змінна перед командою "Експорт" чи після неї. The
Важливо значення змінної під час виконання команди `Build'.
Це те, що розбивається. До речі, будь-які наступні команди "Експортувати"
скасувати першу: ви повинні вказати всі змінні, які ви хочете експортувати для кожної
Команда "Експорт".

Команда Імпортувати команда

Змінні, експортовані командою "Експорт", можна імпортувати в допоміжні сценарії за допомогою
Команда "Імпорт". Допоміжний скрипт завжди імпортує змінні безпосередньо з файлу
кращий сценарій. Розглянемо цей приклад:

Імпорт qw( env INCLUDE );

Це допустимо лише в тому випадку, якщо батьківський сценарій експортував і `$env' і `$INCLUDE'. Це також повинно
надали кожній із цих змінних значення. Можна використовувати лише допоміжний сценарій
імпортувати підмножину експортованих змінних (у цьому прикладі `$LIB', який експортовано за допомогою
попередній приклад не імпортується).

Усі імпортовані змінні автоматично повторно експортуються, тому послідовність:

Імпорт qw ( env INCLUDE );
Збірка qw ( beneath-me/Conscript );

надасть як `$env', так і `$INCLUDE' до допоміжного файлу. Якщо тільки `$env' має бути
експортовано, тоді буде достатньо наступного:

Імпорт qw ( env INCLUDE );
Експортувати qw ( env );
Збірка qw ( beneath-me/Conscript );

Зайве говорити, що змінні можуть бути змінені локально, перш ніж викликати `Build' на
допоміжний сценарій.

Будувати сценарій оцінка порядок

Єдиним обмеженням для впорядкування сценаріїв збірки є те, що є кращими сценаріями
оцінені перед їх нижчими сценаріями. Найвищий рівень Конструкція файл, наприклад, є
спочатку оцінюються, а потім йдуть будь-які нижчі сценарії. Це все, що вам дійсно потрібно знати
про порядок оцінки, оскільки порядок, як правило, не має значення. Розглянемо наступне
Команда `Build':

Побудувати qw(
драйвери/дисплей/призовник
драйвери/миша/строкову службу
парсер/призовник
комунальні послуги/Призовник
);

Ми вирішили розмістити назви сценаріїв в алфавітному порядку, просто тому, що це найбільше
зручний для обслуговування. Зміна порядку не матиме ніякої різниці
будувати

A Model та цінності поділ файли

Дещо простий конвенцій

У будь-якій складній програмній системі має бути метод спільного використання продуктів збірки
встановлений. Ми пропонуємо простий набір умов, які тривіально реалізувати
Мінуси, але дуже ефективні.

Основне правило полягає в тому, щоб вимагати, щоб усі будівельні продукти, які потрібно розподілити між собою
каталоги використовуються спільно через проміжний каталог. Ми зазвичай називаємо це
експорт, а в середовищі C надано звичайні підкаталоги цього каталогу,
такий як включати, либ, Бен, І т.д.

Ці каталоги визначаються верхнім рівнем Конструкція файл. Простий Конструкція файл для
a Здравствуйте, Світ! програма, організована за допомогою кількох каталогів, може виглядати так:

# Створення файлу для Hello, World!

# Де помістити всі наші спільні продукти.
$EXPORT = '#експорт';

Експортувати qw( МІНУЛИ ВХОДЯТЬ LIB BIN );

# Стандартні каталоги для спільного використання продуктів.
$INCLUDE = "$EXPORT/include";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/bin";

# Стандартне будівельне середовище.
$CONS = нові мінуси (
CPPPATH => $INCLUDE, # Включити шлях для компіляцій C
LIBPATH => $LIB, # Шлях до бібліотеки для зв'язування програм
LIBS => '-lworld', # Список стандартних бібліотек
);

Побудувати qw(
привіт/Призовник
світ/Призовник
);

Команда світ каталогів Призовник файл виглядає так:

# Файл Conscript для світу каталогів
Імпорт qw( МІНУСИ ВКЛЮЧАЮТЬ LIB );

# Встановіть продукти цього каталогу
Встановити $CONS $LIB, 'libworld.a';
Встановити $CONS $INCLUDE, 'world.h';

# Внутрішні продукти
Бібліотека $CONS 'libworld.a', 'world.c';

і привіт каталогів Призовник файл виглядає так:

# Файл Conscript для каталогу hello
Імпорт qw( CONS BIN );

# Експортована продукція
Встановіть $CONS $BIN, 'hello';

# Внутрішні продукти
Програма $CONS 'hello', 'hello.c';

Побудувати a Здравствуйте, Світ! програми з такою структурою каталогів, перейдіть на верхній рівень
каталогу та викликати `cons' з відповідними аргументами. У наступному прикладі ми
скажіть Cons, щоб створити каталог експорт. Щоб створити каталог, Cons рекурсивно збирає все
відомі продукти в цьому каталозі (тільки якщо вони потребують перебудови, звичайно). Якщо будь-який з
ці продукти залежать від інших продуктів в інших каталогах, тоді вони будуть створені,
теж.

% мінусів експорту
Установіть world/world.h як export/include/world.h
cc -Iexport/include -c hello/hello.c -o hello/hello.o
cc -Iexport/include -c world/world.c -o world/world.o
ar world/libworld.a world/world.o
ar: створення світу/libworld.a
ranlib world/libworld.a
Встановіть world/libworld.a як export/lib/libworld.a
cc -o привіт/привіт привіт/привіт.o -Lexport/lib -lworld
Встановіть hello/hello як export/bin/hello

Чистий, зрозумілий, незалежний від місця розташування scripts

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

Зверніть також увагу на те, що Cons піклується про дрібні деталі за вас. Всі експорт довідники, для
наприклад, були зроблені автоматично. І встановлені файли були дійсно жорстко пов’язані з файлом
відповідні каталоги експорту, щоб заощадити місце та час. Така увага до деталей рятує
значну роботу, і ще простіше створювати прості, підтримувані сценарії.

Роздільний джерело та будувати дерева

Часто бажано зберігати будь-які похідні файли зі збірки повністю окремо від файлу
вихідні файли. Це значно полегшує відстеження того, що є вихідним файлом і
також полегшує обробку варіант збірки, особливо якщо вам потрібні варіанти збірок
співіснувати.

Роздільний будувати та джерело каталоги використання посилання команда

Мінуси забезпечує простий механізм, який відповідає всім цим вимогам. `Посилання'
команда викликається, як у цьому прикладі:

Посилання 'build' => 'src';

Вказані каталоги ``пов’язані'' із зазначеним вихідним каталогом. Припустимо
що ви налаштували вихідний каталог, SRC, з підкаталогами світ та привіт під ним,
як у попередньому прикладі. Потім ви можете замінити оригінальні лінії збірки
наступні:

Побудувати qw(
build/world/Призовник
build/привіт/призовник
);

Зверніть увагу, що ви лікуєте Призовник файл так, ніби він існував у каталозі збірки. Тепер якщо
ви введете ту саму команду, що й раніше, ви отримаєте такі результати:

% мінусів експорту
Встановіть build/world/world.h як export/include/world.h
cc -Iexport/include -c build/hello/hello.c -o build/hello/hello.o
cc -Iexport/include -c build/world/world.c -o build/world/world.o
ar r build/world/libworld.a build/world/world.o
ar: створення build/world/libworld.a
ranlib build/world/libworld.a
Встановіть build/world/libworld.a як export/lib/libworld.a
cc -o build/hello/hello build/hello/hello.o -Lexport/lib -lworld
Встановіть build/hello/hello як export/bin/hello

Знову ж таки, Cons подбає про деталі за вас. Зокрема, ви помітите, що все
збірки виконуються з використанням вихідних файлів і об’єктних файлів з каталогу збірки. Для
наприклад, будувати/світ/світ.о складено з build/world/world.c та
export/include/world.h встановлюється з build/world/world.h. Це досягається на більшості
системи за допомогою простого засобу "жорсткого" зв'язування необхідних файлів з кожного джерела
каталог у відповідний каталог збірки.

Посилання підтримуються правильно за допомогою Cons, незалежно від того, що ви робите з вихідним каталогом.
Якщо ви змінюєте вихідний файл, ваш редактор може зробити це «на місці» або перейменувати його
спочатку і створіть новий файл. В останньому випадку будь-яке жорстке посилання буде втрачено. Мінуси будуть
виявити цю умову наступного разу, коли знадобиться вихідний файл, і повторно зв’яже його
відповідним чином.

Ви, до речі, це також помітите немає вимагалися зміни основного Призовник
файли. І ми можемо піти далі, як ми побачимо в наступному розділі.

варіант Будує

Здравствуйте, Світ! та цінності баНаНа та персиковий ОС

Варіантні збірки вимагають ще одного простого розширення. Візьмемо як приклад а
вимога дозволити збірки для операційних систем baNaNa і peAcH. В цьому випадку,
ми використовуємо розподілену файлову систему, таку як NFS для доступу до певної системи, і
тільки одна чи інша з систем має бути скомпільована для будь-якого даного виклику
`мінуси'. Ось один із способів налаштування Конструкція файл для нашого Здравствуйте, Світ!
Додаток:

# Створення файлу для Hello, World!

die qq (ОС має бути вказана), якщо $OS = $ARG{OS};
die qq(ОС має бути "персик" або "банан")
якщо $OS ne "персик" && $OS ne "банан";

# Де помістити всі наші спільні продукти.
$EXPORT = "#export/$OS";

Експортувати qw( МІНУЛИ ВХОДЯТЬ LIB BIN );

# Стандартні каталоги для спільного використання продуктів.
$INCLUDE = "$EXPORT/include";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/bin";

# Стандартне будівельне середовище.
$CONS = нові мінуси (
CPPPATH => $INCLUDE, # Включити шлях для компіляцій C
LIBPATH => $LIB, # Шлях до бібліотеки для зв'язування програм
LIBS => '-lworld', # Список стандартних бібліотек
);

# $BUILD – це те місце, де ми отримаємо все.
$BUILD = "#build/$OS";

# Вкажіть мінуси, де знаходяться вихідні файли для $BUILD.
Посилання $BUILD => 'src';

Збірка (
"$BUILD/привіт/Призовник",
"$BUILD/world/Призовник",
);

Тепер, якщо ми увійдемо в систему peAcH, ми зможемо створити нашу Здравствуйте, Світ! заявка на це
платформа:

% мінусів експорту ОС=персик
Встановіть build/peach/world/world.h як export/peach/include/world.h
cc -Iexport/peach/include -c build/peach/hello/hello.c -o build/peach/hello/hello.o
cc -Iexport/peach/include -c build/peach/world/world.c -o build/peach/world/world.o
ar r build/peach/world/libworld.a build/peach/world/world.o
ar: створення build/peach/world/libworld.a
ranlib build/peach/world/libworld.a
Встановіть build/peach/world/libworld.a як export/peach/lib/libworld.a
cc -o build/peach/hello/hello build/peach/hello/hello.o -Lexport/peach/lib -lworld
Встановіть build/peach/hello/hello як export/peach/bin/hello

Варіації on a тема

Можливі й інші варіації цієї моделі. Наприклад, ви можете вирішити, що хочете
щоб розділити ваші включені файли на файли, залежні від платформи та незалежні від платформи.
У цьому випадку вам доведеться визначити альтернативу `$INCLUDE' для залежно від платформи
файли. Більшість Призовник файли, створюючи суто незалежні від платформи включаються файли
не треба змінювати.

Ви також можете мати можливість зібрати всю вашу систему за допомогою налагодження або профілювання,
наприклад, увімкнено. Ви можете зробити це за допомогою відповідних параметрів командного рядка, наприклад
`DEBUG=on'. Потім це буде переведено на відповідну платформу
вимоги для ввімкнення налагодження (це може включати вимкнення оптимізації, for
приклад). Ви можете за бажанням змінити простір імен для цих різних типів систем,
але, як ми побачимо в наступному розділі, це не так істотний щоб зробити це, оскільки мінуси досить
розумно відновлювати речі, коли ви змінюєте параметри.

Signatures

MD5 криптографічні підпису

Щоразу, коли Cons створює похідний файл, він зберігає a підпис для цього файлу. Підпис
зберігається в окремому файлі, по одному на каталог. Після компіляції попереднього прикладу,
.consign файл у файлі побудувати/персик/світ каталог виглядав так:

world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
libworld.a:834179304 9bf6587fa06ec49d864811a105222c00

Перше число є міткою часу - для систем UNIX це, як правило, число
секунд з 1 січня 1970 року. Друге значення — контрольна сума MD5. The Повідомлення Digest
Алгоритм – це алгоритм, який за вхідним рядком обчислює надійну криптографію
підпис для цього рядка. Контрольна сума MD5, що зберігається в файлі .consign файл, по суті, є a
дайджест всієї інформації про залежності для вказаного файлу. Так, наприклад, для
world.o файл, це включає принаймні файл world.c файл, а також будь-які заголовні файли, які Cons
знає про те, що включені, прямо чи опосередковано world.c. Мало того, але й
фактичний командний рядок, який використовувався для створення world.o також вводиться в обчислення
підпис. так само, libworld.a отримує підпис, який "включає" всі
підписи її складових (а отже, транзитно, підписи їх
складові), а також командний рядок, у якому створено файл.

Сигнатура непохідного файлу за замовчуванням обчислюється за допомогою поточного
час зміни файлу та ім’я запису (якщо не буде a
ток .consign запис для цього файлу, у цьому випадку використовується цей підпис).

Зауважте, що похідний файл не повинен залежати від будь-якого конкретного Конструкція or
Призовник файл – якщо зміни до цих файлів впливають на відповідний файл, то це буде
автоматично відображається в його підписі, оскільки відповідні частини командного рядка є
включено в підпис. Непов’язані зміни не матимуть ніякого ефекту.

Коли Cons обмірковує, чи отримувати певний файл, він спочатку обчислює
очікуваний підпис файлу. Потім він порівнює час останньої зміни файлу з
час, записаний у .consign запис, якщо такий існує. Якщо ці часи збігаються, то
підпис, що зберігається в .consign файл вважається точним. Якщо файл попередній
підпис не відповідає новому очікуваному підпису, то файл потрібно отримати повторно.

Зауважте, що файл буде повторно отримано щоразу, коли щось про залежний файл змінюється. в
зокрема, зверніть увагу на це будь-який змінити час модифікації залежного (вперед або
назад у часі) призведе до повторної компіляції похідного файлу.

Використання цих підписів є надзвичайно простим, ефективним та ефективним методом
різко покращуючи відтворюваність системи.

Ми продемонструємо це на простому прикладі:

# Просте "Привіт, світ!" Побудувати файл
$CFLAGS = '-g', якщо $ARG{DEBUG} eq 'on';
$CONS = нові мінуси (CFLAGS => $CFLAGS);
Програма $CONS 'hello', 'hello.c';

Зверніть увагу, як Cons перекомпілюється у відповідний час:

% мінуси привіт
cc -c привіт.c -o привіт.о
cc -o привіт hello.o
% мінуси привіт
мінуси: «привіт» актуальний.
% мінуси DEBUG=на привіт
cc -g -c привіт.c -o привіт.о
cc -o привіт hello.o
% мінуси DEBUG=на привіт
мінуси: «привіт» актуальний.
% мінуси привіт
cc -c привіт.c -o привіт.о
cc -o привіт hello.o

код Сховища

Багато організацій, що займаються розробкою програмного забезпечення, матимуть один або декілька каталогів центрального сховища
дерева, що містять поточний вихідний код для одного або кількох проектів, а також похідні
об’єктні файли, бібліотеки та виконувані файли. Щоб зменшити непотрібну перекомпіляцію,
корисно використовувати файли зі сховища для створення програмного забезпечення для розробки - припускаючи, що
звичайно, що в локальному дереві збірки немає новішого файлу залежностей.

Сховище

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

Наступні рядки в а Конструкція файл вказує Cons спочатку шукати під файлом
/usr/experiment/repository каталогу, а потім під /usr/product/repository каталог:

Репозиторій qw (
/usr/experiment/repository
/usr/product/repository
);

Вказані каталоги сховища можуть містити вихідні файли, похідні файли (об’єкти,
бібліотеки та виконувані файли) або обидва. Якщо немає локального файлу (джерельного чи похідного) під
каталог, у якому виконується Cons, потім знайдена перша копія файлу з такою ж назвою
у каталозі репозиторію буде використовуватися для створення будь-яких локальних похідних файлів.

Cons підтримує один глобальний список каталогів сховищ. Мінуси усунуть
поточний каталог і будь-які неіснуючі каталоги зі списку.

Виявлення Конструкція файл in a Сховище

Мінуси також будуть шукати Конструкція та Призовник файли в дереві сховища або деревах.
Однак це призводить до ситуації «курка та яйце»: як ви виглядаєте в дереві сховища?
для Конструкція файл, якщо Конструкція файл повідомляє вам, де знаходиться сховище? Отримати
навколо цього репозиторії можна вказати за допомогою параметрів `-R' у командному рядку:

% мінусів -R /usr/experiment/repository -R /usr/product/repository .

Будь-які каталоги сховища, зазначені в Конструкція or Призовник файли будуть додані
до каталогів сховища, визначених параметрами `-R' командного рядка.

Сховище джерело файли

Якщо вихідний код (включаючи файл Призовник файл) для версії бібліотеки Здравствуйте,
Світ! Програма C знаходиться в репозиторії (без похідних файлів), Cons використовуватиме файл
вихідні файли репозиторію, щоб створити локальні об'єктні файли та виконуваний файл:

% мінусів -R /usr/src_only/repository привіт
gcc -c /usr/src_only/repository/hello.c -o hello.o
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: створення libworld.a
ranlib libworld.a
gcc -o привіт привіт.o libworld.a

Створення локального вихідного файлу змусить Cons перебудувати відповідний похідний файл або
файли:

% Pico world.c
[EDIT]
% мінусів -R /usr/src_only/repository привіт
gcc -c світ.c -o світ.о
ar r libworld.a world.o
ar: створення libworld.a
ranlib libworld.a
gcc -o привіт привіт.o libworld.a

А видалення локального вихідного файлу призведе до повернення до створення похідного
файли з джерела репозиторію:

% середньоквадратичного значення світу.c
% мінусів -R /usr/src_only/repository привіт
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: створення libworld.a
ranlib libworld.a
gcc -o привіт привіт.o libworld.a

Сховище отримані файли

Якщо дерево сховища містить похідні файли (зазвичай об’єктні файли, бібліотеки або
виконувані файли), Cons виконає свій звичайний розрахунок підпису, щоб вирішити, чи
файл репозиторію оновлений або похідний файл має бути створений локально. Це означає що,
для забезпечення правильного обчислення підпису дерево сховища також має містити
.consign файли, які були створені Cons під час створення похідних файлів.

Зазвичай це досягається шляхом створення програмного забезпечення в репозиторії (або,
як альтернатива, у каталозі збірки, а потім скопіювати результат у сховище):

% cd /usr/all/repository
% мінуси привіт
gcc -c привіт.c -o привіт.о
gcc -c світ.c -o світ.о
ar r libworld.a world.o
ar: створення libworld.a
ranlib libworld.a
gcc -o привіт привіт.o libworld.a

(Це безпечно, навіть якщо Конструкція файл містить список /usr/all/repository каталог в a
Команда `Repository', оскільки Cons видалить поточний каталог зі сховища
список.)

Тепер, якщо ми хочемо створити копію програми за допомогою нашого власного привіт.c файл, нам тільки потрібен
щоб створити один необхідний вихідний файл, і використовуйте параметр `-R', щоб Cons використовував інший
файли зі сховища:

% mkdir $HOME/build1
% CD $HOME/build1
% ed привіт.c
[EDIT]
% мінусів -R /usr/all/repository привіт
gcc -c привіт.c -o привіт.о
gcc -o привіт привіт.o /usr/all/repository/libworld.a

Зверніть увагу, що Cons не потрудився відтворити локальний libworld.a бібліотеку (або перекомпілюйте файл
world.o module), але замість цього використовує вже скомпільовану версію зі сховища.

Тому що підписи MD5, які Cons ставить в .consign файл містить позначки часу для
похідних файлів, мітки часу підпису повинні відповідати міткам часу файлу для підпису
вважати дійсними.

Деякі програмні системи можуть змінювати часові позначки на файлах репозиторію (копіюючи їх,
наприклад), у цьому випадку Cons за замовчуванням вважатиме, що підписи репозиторію недійсні
і перебудувати файли без потреби. Цю поведінку можна змінити, вказавши:

Repository_Sig_Times_OK 0;

Це вказує Cons ігнорувати позначки часу, коли вирішує, чи є підпис дійсним. (Примітка
що уникнення цієї перевірки означає, що над сховищем має бути належний контроль
дерево, щоб гарантувати, що похідні файли неможливо змінити без оновлення файлу .consign
підпис.)

Місцевий copies of файли

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

% mkdir $HOME/build2
% CD $HOME/build2
% мінусів -R /usr/all/repository привіт
мінуси: «привіт» актуальний.

Чому Cons каже, що привіт програма актуальна, коли немає привіт програми в
локальний каталог збірки? Оскільки репозиторій (не локальний каталог) містить файл
відповідний сучасним вимогам привіт Програма, а Cons правильно визначає, що нічого робити не потрібно
перебудуйте цю оновлену копію файлу.

Однак є багато випадків, коли доцільно переконатися, що локальна копія a
файл завжди існує. Наприклад, сценарій упаковки або тестування може припускати, що це певно
створені файли існують локально. Замість того, щоб повідомляти про допоміжні сценарії
каталогу сховища, команду `Локальний' можна додати до a Конструкція or Призовник файл в
вкажіть, що певний файл або файли повинні з'являтися в локальному каталозі збірки:

Локальний qw(
привіт
);

Потім, якщо ми повторно запустимо ту саму команду, Cons зробить локальну копію програми з файлу
копія репозиторію (що повідомляє вам, що це робить):

% мінусів -R /usr/all/repository привіт
Локальна копія hello з /usr/all/repository/hello
мінуси: «привіт» актуальний.

Зауважте, що, оскільки акт створення локальної копії не вважається «побудовою» файлу
привіт файл, Cons все ще повідомляє, що він оновлений.

Створення локальних копій є найбільш корисним для файлів, які встановлюються в файл
проміжний каталог (для спільного використання з іншими каталогами) за допомогою команди `Install'.
Команда «Встановити» для файлу супроводжується командою «Локальна»
Зазвичай Cons надає команду `Install_Local' як зручний спосіб зробити обидва:

Install_Local $env, '#export', 'hello';

еквівалентно:

Встановіть $env '#export', 'hello';
Локальний '#export/hello';

Команди `Local' і `Install_Local' оновлюють локальну .consign файл з
відповідні підписи файлів, щоб майбутні збірки виконувались правильно.

Сховище залежність аналіз

Завдяки вбудованому скануванню, Cons буде шукати включені у вказаних деревах сховища
.h файли. Проте, якщо компілятор також не знає про дерева репозиторію, це буде так
не можу знайти .h файли, які існують лише в репозиторії. Якщо, наприклад, привіт.c
файл містить файл привіт.ч файл у поточному каталозі:

% мінусів -R /usr/all/repository привіт
gcc -c /usr/all/repository/hello.c -o hello.o
/usr/all/repository/hello.c:1: hello.h: такого файлу чи каталогу немає

Вирішення цієї проблеми висуває певні вимоги до середовища будівництва
визначено і на те, як директива препроцесора C `#include' використовується для включення файлів.

Щоб повідомити компілятору про дерева сховища, Cons додасть відповідний `-I'
прапори до команд компіляції. Це означає, що змінна `CPPPATH' у файлі
Конструктивне середовище має явно вказувати всі підкаталоги, які потрібно шукати
для включених файлів, включаючи поточний каталог. Отже, ми можемо виправити вищесказане
Наприклад, змінюючи середовище створення в Конструкція файл наступним чином:

$env = нові мінуси (
CC => 'gcc',
CPPPATH => '.',
LIBS => 'libworld.a',
);

Завдяки визначенню змінної `CPPPATH' це дає результат, коли ми повторно виконуємо
команда:

% мінусів -R /usr/all/repository привіт
gcc -c -I. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
gcc -o привіт привіт.o /usr/all/repository/libworld.a

Порядок прапорів `-I' реплікує, для препроцесора C, той самий репозиторій-
шлях пошуку каталогу, який Cons використовує для власного аналізу залежностей. Якщо є
кілька сховищ і кілька каталогів `CPPPATH', мінуси додадуть репозиторій
каталогів до початку кожного каталогу `CPPPATH', швидко збільшуючи число
прапорів `-I'. Як крайній приклад, а Конструкція файл, що містить:

репозиторій qw(
/u1
/u2
);

$env = нові мінуси (
CPPPATH => 'a:b:c',
);

Дасть команду компіляції:

cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c привіт.c -o привіт.о

Оскільки Cons покладається на прапорці `-I' компілятора для передачі порядку, в якому
каталоги сховища потрібно шукати, мінуси в обробці каталогів репозиторіїв
принципово несумісний із використанням подвійних лапок у директивах `#include' у вашому C
вихідний код:

#include "file.h" /* НЕ ВИКОРИСТОВУЙТЕ ТАКІ ПОДВІЙНІ лапки */

Це тому, що більшість препроцесорів C, коли стикаються з такою директивою, завжди будуть першими
пошук у каталозі, що містить вихідний файл. Це підриває продумане "-я"
параметри, які Cons конструює, щоб зробити препроцесор відповідним його бажаному пошуку
шлях

Отже, при використанні дерев репозиторію в Cons, завжди використовуйте кутові дужки для включеного
файли:

#включати /* ВИКОРИСТОВУЙТЕ ЗАМІСТЬ КУТОВІ СКОЖКИ */

Repository_List

Cons надає команду `Repository_List' для повернення списку всіх каталогів сховища
у поточному порядку пошуку. Це можна використовувати для налагодження або для більш складного Perl
матеріал:

@list = Список_сховища;
print join(' ', @list), "\n";

Сховище взаємодія з інший мінуси риси

Обробка дерев сховища мінусами коректно взаємодіє з іншими функціями мінусів, а саме
сказати, як правило, робить те, що ви очікували.

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

дефолт цілі

До цих пір ми демонстрували виклик Cons з явною метою для створення:

% мінуси привіт

Зазвичай Cons нічого не створює, якщо не вказано ціль, але вказує '.'
(поточний каталог) побудує все:

% cons # нічого не створює

% мінусів. # створює все в каталозі верхнього рівня

Додавання методу `Default' до будь-якого Конструкція or Призовник файл додасть вказаний
цілі до списку цілей за замовчуванням. Мінуси створять ці значення за замовчуванням, якщо їх немає
цілі, зазначені в командному рядку. Таким чином, додайте наступний рядок на верхній рівень
Конструкція файл буде імітувати типову поведінку Make, яка створює все за замовчуванням:

За замовчуванням '.';

Наступне додало б привіт та до побачення команди (в тому ж каталозі, що й файл
Конструкція or Призовник файл) до списку за замовчуванням:

За замовчуванням qw(
привіт
до побачення
);

Метод «За замовчуванням» можна використовувати кілька разів, щоб додати цілі до списку за замовчуванням.

Селективний Будує

Мінуси передбачає два способи зменшення розміру даної збірки. По-перше, шляхом уточнення
цілі в командному рядку, а другий — це метод обрізання дерева збірки. Добре
спочатку розглянемо цільову специфікацію.

Селективний націлювання

Як і make, Cons дозволяє вказувати ``цілі'' в командному рядку. Мінуси цілі
можуть бути файлами або каталогами. Коли вказано каталог, це просто короткий-
ручне позначення для кожного похідного продукту, про який знає Cons, у зазначеному
каталог і нижче. Наприклад:

% мінусів build/hello/hello.o

означає будувати привіт.о і все те привіт.о може знадобитися. Це з попереднього
версія Здравствуйте, Світ! програма, в якій привіт.о залежав від
export/include/world.h. Якщо цей файл не оновлений (оскільки хтось змінив
src/світ/світ.h), то він буде перебудований, навіть якщо він знаходиться у каталозі, віддаленому від
побудувати/привіт.

У цьому прикладі:

% мінусів побудови

Все в будувати каталог будується, якщо необхідно. Знову ж таки, це може призвести до збільшення кількості файлів
бути побудований. Зокрема, обидва export/include/world.h та export/lib/libworld.a він має
вимагає побудувати/привіт каталог, тому вони будуть створені, якщо вони застаріли.

Якщо ми це зробимо, замість цього:

% мінусів експорту

тоді будуть перебудовані лише ті файли, які мають бути встановлені в каталозі експорту, якщо
необхідно, а потім встановлюють там. Зауважте, що `cons build' може створювати файли, які мають `cons
export' не створюється, і навпаки.

Немає ``особливий'' цілі

З мінусами, ``спеціальні'' цілі не потрібні. Найпростіший аналог з мінусами
полягає у використанні спец експорт натомість каталоги. Припустимо, наприклад, що у вас є a
ціла серія модульних тестів, пов’язаних з вашим кодом. Тести живуть у
вихідний каталог біля коду. Однак зазвичай ви не хочете створювати ці тести.
Одним із рішень є надання всіх інструкцій зі створення тестів, а потім до
встановити тести в окрему частину дерева. Якщо ми встановимо тести на верхньому рівні
довідник називається Тести, тоді:

% мінусів тестів

побудує всі тести.

% мінусів експорту

створить робочу версію системи (але не тести), і:

% мінусів побудови

цього, ймовірно, слід уникати (оскільки це буде компілювати тести без потреби).

Якщо ви хочете створити лише один тест, ви можете явно назвати тест (in
або Тести каталог або будувати каталог). Ви також можете об’єднати тести
у зручну ієрархію в каталозі тестів. Ця ієрархія не потрібна
обов'язково відповідає ієрархії джерела, майже так само, як ієрархія включення
ймовірно, не відповідає ієрархії джерела (ієрархія включення навряд чи буде більше
ніж два рівні глибини, для програм на C).

Якщо ви хочете побудувати абсолютно все в дереві (з урахуванням будь-яких варіантів
виберіть), ви можете використовувати:

% мінусів.

Це не особливо ефективно, так як буде зайво обходити всі дерева,
включаючи вихідне дерево. У вихідному дереві, звичайно, можуть бути об’єкти, які можна побудувати
це – ніщо не заважає вам зробити це, навіть якщо ви зазвичай збираєтеся в окремій збірці
дерево.

Будувати Обрізка

У поєднанні з вибором цілі, будувати обрізка можна використовувати для зменшення обсягу
будувати. У попередньому прикладі peAcH і baNaNa ми вже бачили, як керується сценарієм
Обрізка збірки може бути використана, щоб зробити доступною лише половину потенційної збірки для будь-якого даного
виклик "мінуси". Cons також передбачає, як зручність, конвенцію командного рядка, яка
дозволяє вказати який Призовник файли фактично ``будуються'', тобто включаються
в дерево побудови. Наприклад:

% мінусів build +world

Аргумент "+" вводить регулярний вираз Perl. Це, звісно, ​​треба процитувати
рівень оболонки, якщо у виразі є метасимволи оболонки. The
вираз відповідає кожному Призовник файл, який був згаданий у "Build"
і лише ті сценарії з відповідними іменами фактично включені до
побудувати дерево. Допускається кілька таких аргументів, у цьому випадку збіг проти будь-якого з них
достатньо для включення сценарію.

У наведеному вище прикладі привіт Програма не буде побудована, оскільки мінусів не буде
знання сценарію привіт/Призовник, libworld.a архів буде створено, однак, якщо
потрібно.

Існує кілька варіантів використання обрізання збірки за допомогою командного рядка. Мабуть, найкорисніший
це здатність вносити локальні зміни, а потім, з достатнім знанням про
наслідки цих змін, обмежити розмір дерева побудови для прискорення
час перебудови. Друге використання обрізання збірки — активне запобігання перекомпіляції
певних файлів, які, як ви знаєте, перекомпілюються, наприклад, завдяки зміненому заголовному файлу.
Можливо, ви знаєте, що зміни до заголовного файлу є несуттєвими, або те, що
зміни можна безпечно ігнорувати для більшої частини дерева для цілей тестування
думка полягає в тому, що прагматично визнавати такий тип поведінки, розуміючи, що
на наступній повній збірці буде все, що потрібно перебудувати. Немає еквіваленту
на команду ``make touch'', щоб позначити файли як постійно оновлені. Отже, будь-який ризик
пом’якшується обрізка нарощування. Для випуску якісну роботу, очевидно, рекомендуємо
що ви не використовуєте обрізання збірки (однак це цілком нормально використовувати під час інтеграції,
для перевірки компіляції тощо. Просто не забудьте зробити необмежену збірку перед фіксацією
інтеграція).

Тимчасовий перевизначає

Мінуси надає дуже простий механізм для перевизначення аспектів збірки. Суть в тому
що ви пишете файл перевизначення, що містить одну або кілька команд `Override', і ви
вкажіть це в командному рядку, коли ви запускаєте `cons':

% мінусів -o над експортом

буде будувати експорт каталогу з усіма похідними файлами, які підлягають перевизначенням
в над файл. Якщо ви пропустите параметр `-o', тоді все необхідне видалити
всі перевизначники будуть відновлені.

Переважаючий навколишнє середовище змінні

Файл перевизначення може містити два типи перевизначення. Перше – це навколишнє середовище
змінні. Зазвичай вони доступні для Конструкція файл із хешу `%ENV'
змінний. Їх можна тривіально змінити у файлі перевизначення, встановивши параметр
відповідні елементи `%ENV' (їх також можна замінити в середовищі користувача,
звичайно).

Команда Override команда

Другий тип перевизначення виконується за допомогою команди `Override', яка виглядає так
це:

Перевизначити , => , => , ...;

Регулярний вираз RegExp співставляється з кожним похідним файлом, який є кандидатом
для побудови. Якщо похідний файл збігається, то використовуються пари змінна/значення
замінити значення в середовищі побудови, пов’язаного з похідним файлом.

Припустимо, що у нас таке середовище будівництва:

$CONS = нові мінуси (
COPT => '',
CDBG => '-g',
CFLAGS => '%COPT %CDBG',
);

Тоді, якщо у нас є файл перевизначення над містить цю команду:

Замінити '\.o$', COPT => '-O', CDBG => '';

потім будь-який виклик "против" з "-o over", який створює .o файли через це середовище буде
змушують їх компілювати з `-O 'і без `-g'. Перевизначення, звичайно, могло бути
обмежений одним каталогом за допомогою відповідного вибору регулярного виразу.

Ось оригінальна версія Hello, World! програму, створену з цим середовищем.
Зауважте, що Cons відновлює відповідні частини, коли заміна застосовується або видаляється:

% мінуси привіт
cc -g -c привіт.c -o привіт.о
cc -o привіт hello.o
% мінуси -o над привіт
cc -O -c привіт.c -o привіт.o
cc -o привіт hello.o
% мінуси -o над привіт
мінуси: «привіт» актуальний.
% мінуси привіт
cc -g -c привіт.c -o привіт.о
cc -o привіт hello.o

Важливо, щоб команда `Override' використовувалася лише для тимчасового, на льоту
перевизначення, необхідні для розробки, оскільки перевизначення не є незалежними від платформи та
тому що вони надто покладаються на глибоке знання роботи сценаріїв. Для
тимчасове використання, однак вони саме те, що ви хочете.

Зауважте, що все одно корисно надати, скажімо, можливість створення повністю оптимізованого
версія системи для виробничого використання -- з Конструкція та Призовник файли. Сюди
ви можете адаптувати оптимізовану систему до платформи. Де потрібні компроміси з оптимізатором
зроблено (наприклад, певні файли можуть бути не скомпільовані з повною оптимізацією).
вони можуть бути записані для нащадків (і відтворюваності) безпосередньо в сценаріях.

більше on будівництво середовищах

дефолт будівництво змінні

Ми згадували та використовували поняття a будівництво навколишнє середовище, багато разів у
попередні сторінки. Тепер настав час зробити це трохи більш конкретним. З наступним
заява:

$env = нові мінуси ();

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

CC => 'cc',
CFLAGS => '',
CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
INCDIRPREFIX => '-I',
CXX => '%CC',
CXXFLAGS => '%CFLAGS',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS -c %< -o %>',
LINK => '%CXX',
LINKCOM => '%LINK %LDFLAGS -o %> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD -r -o %> %<',
LIBDIRPREFIX => '-L',
AR => 'ar',
ARFLAGS => 'r',
ARCOM => "%AR %ARFLAGS %> %<\n%RANLIB %>",
RANLIB => 'ranlib',
AS => 'як',
ASFLAGS => '',
ASCOM => '%AS %ASFLAGS %< -o %>',
LD => 'ld',
LDFLAGS => '',
PREFLIB => 'lib',
SUFLIB => '.a',
SUFLIBS => '.so:.a',
SUFOBJ => '.o',
ENV => { 'PATH' => '/ bin:/ usr / bin'},

У системах Win32 (Windows NT) наступні конструкційні змінні замінюються в
за замовчуванням:

CC => 'cl',
CFLAGS => '/nologo',
CCCOM => '%CC %CFLAGS %_IFLAGS /c %< /Fo%>',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS /c %< /Fo%>',
INCDIRPREFIX => '/I',
LINK => 'посилання',
LINKCOM => '%LINK %LDFLAGS /out:%> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD /r /o %> %<',
LIBDIRPREFIX => '/LIBPATH:',
AR => 'lib',
ARFLAGS => '/nologo ',
ARCOM => "%AR %ARFLAGS /out:%> %<",
RANLIB => '',
LD => 'посилання',
LDFLAGS => '/nologo ',
PREFLIB => '',
SUFEXE => '.exe',
SUFLIB => '.lib',
SUFLIBS => '.dll:.lib',
SUFOBJ => '.obj',

Ці змінні використовуються різними методами, пов’язаними з середовищем, в
зокрема будь-який метод, який в кінцевому підсумку викликає зовнішню команду, замінить їх
змінні в кінцеву команду, як доречно. Наприклад, метод `Objects' бере
ряд вихідних файлів і організовує отримання, якщо необхідно, відповідного об'єкта
файли. Наприклад:

Об'єкти $env 'foo.c', 'bar.c';

Це дозволить виготовити, якщо необхідно, foo.o та бар.о. Викликана команда проста
`%CCCOM', який розширюється шляхом заміни, до потрібної зовнішньої команди
побудувати кожен об’єкт. Ми розглянемо правила заміни далі під «Командою»
метод, нижче.

Конструкційні змінні також використовуються для інших цілей. Наприклад, `CPPPATH' є
використовується для визначення шляху до каталогів включення, розділених двокрапкою. Вони призначені бути
передаються в препроцесор C і також використовуються машиною для сканування файлів C
визначити залежності, які беруть участь у компіляції C. Змінні, які починаються з
підкреслення, створюються різними методами, і зазвичай їх слід вважати "внутрішніми"
змінні. Наприклад, коли викликається метод, який вимагає створення об’єкта
з джерела C створюється змінна `_IFLAGS': це відповідає перемикачам `-I'
компілятор C повинен представляти каталоги, визначені `CPPPATH'.

Зауважте, що для будь-якого конкретного середовища значення змінної встановлюється один раз, а потім
ніколи не скидати (щоб змінити змінну, необхідно створити нове середовище. Методи надаються
для копіювання існуючих середовищ для цієї мети). Деякі внутрішні змінні, наприклад
`_IFLAGS' створюються на вимогу, але після встановлення вони залишаються фіксованими протягом усього життя
довкілля.

Усі змінні `CFLAGS', `LDFLAGS' та `ARFLAGS' забезпечують місце для передачі параметрів до
компілятор, завантажувач і архіватор відповідно. Менш очевидно, що "INCDIRPREFIX"
змінна визначає рядок параметрів, який буде додано до початку кожного включення
каталог, щоб компілятор знав, де його знайти .h файли. Так само,
Змінна `LIBDIRPREFIX' визначає рядок параметра, який буде додано до початку
кожен каталог, у якому компонувальник повинен шукати бібліотеки.

Інша змінна, `ENV', використовується для визначення системного середовища під час виконання
зовнішньої команди. За замовчуванням єдиною змінною середовища, яка встановлюється, є `PATH',
який є шляхом виконання команди UNIX. Для максимальної відтворюваності потрібно
дійсно організувати встановлення власного шляху виконання на вашому верхньому рівні Конструкція файл (або
можливо, імпортуючи відповідний конструкційний пакет за допомогою команди Perl `use'). The
Змінні за замовчуванням призначені для того, щоб підняти вас.

Інтерполяція будівництво змінні

Змінні середовища конструювання можуть бути інтерпольовані в імена вихідного та цільового файлів
шляхом додавання до імені змінної конструкції префікса `%'.

$env = нові мінуси (
DESTDIR => 'програми',
SRCDIR => 'src',
);
Програма $env '%DESTDIR/hello', '%SRCDIR/hello.c';

Розширення конструкційних змінних є рекурсивним, тобто файлом ім'я(s) буде повторно
розширюється до тих пір, поки не можна буде робити заміни. Якщо конструкційна змінна не є
визначено в середовищі, тоді буде замінено нульовий рядок.

дефолт будівництво методика

Список методів побудови за замовчуванням включає наступне:

Команда `новий' конструктор

Метод `new' є конструктором об'єктів Perl. Тобто він не викликається через посилання
до існуючого будівельного середовища посилання, але, досить статично, використовуючи назву
з Perl пакет де визначено конструктор. Метод викликається таким чином:

$env = нові мінуси ( );

Середовище, яке ви отримуєте назад, міститься в пакеті «мінуси», що означає, що воно буде
пов'язали з ним методи за замовчуванням, описані нижче. Індивідуальне будівництво
змінні можна замінити, надавши пари ім'я/значення в списку замін. Зауважте, що
щоб замінити будь-яку змінну середовища команди (тобто будь-що під `ENV'), вам доведеться
перевизначити їх усі. Ви можете обійти цю складність, використовуючи метод `copy' на файлі
існуюче будівельне середовище.

Команда `клон' метод

Метод `clone' створює клон існуючого середовища побудови і може бути
називається, як у наступному прикладі:

$env2 = $env1->clone( );

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

Команда `копіювати' метод

Метод `copy' витягує визначені ззовні змінні конструкції з an
середовища та повертає їх у вигляді списку пар ім’я/значення. Перевизначення також можуть бути
за умови, і в цьому випадку перевизначені значення будуть повернуті відповідно до необхідності. The
повернутий список можна призначити хешу, як показано в прототипі нижче, але також можна
маніпулювати іншими способами:

%env = $env1->copy( );

Значення `ENV', яке само по собі є хешем, також копіюється в новий хеш, тому це може бути
змінювався, не боячись вплинути на початкове середовище. Так, наприклад, якщо ви дійсно
якщо ви хочете замінити лише змінну `PATH' у середовищі за замовчуванням, ви можете зробити так
наступні:

%cons = new cons()->copy();
$cons{ENV}{PATH} = " ";
$cons = нові мінуси (%cons);

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

Команда `Встановити' метод

Метод `Install' організовує встановлення вказаних файлів у вказаному
каталог. Встановлення оптимізовано: файл не копіюється, якщо його можна зв’язати. Якщо
це не бажана поведінка, вам потрібно буде використовувати інший метод для встановлення
файл. Називається він так:

Встановіть $env , ;

Зауважте, що, хоча файли, які будуть встановлені, можуть мати довільні імена, але тільки останні
компонент кожного імені використовується для встановленого цільового імені. Так, наприклад, якщо ви
домовитися про встановлення foo/бар in Baz, це створить a бар файл у файлі Baz каталог (ні
foo/бар).

Команда `InstallAs' метод

Метод `InstallAs' організовує для вказаного джерела файл(s) для встановлення як
зазначена ціль файл(s). Кілька файлів слід вказати як список файлів. The
встановлення оптимізовано: файл не копіюється, якщо його можна зв’язати. Якщо це не те
бажаної поведінки, вам потрібно буде використовувати інший метод для встановлення файлу. це є
називається так:

`InstallAs' працює двома способами:

Встановлення одного файлу:

InstallAs $env TgtFile, SrcFile;

Встановлення кількох файлів:

InstallAs $env ['tgt1', 'tgt2'], ['src1', 'src2'];

Або навіть як:

@srcs = qw(src1 src2 src3);
@tgts = qw(tgt1 tgt2 tgt3);
InstallAs $env [@tgts], [@srcs];

Списки цільових і джерел мають бути однакової довжини.

Команда `дорогоцінний' метод

Метод `Precious' вимагає від мінусів не видаляти вказаний файл або список файлів раніше
будує їх знову. Викликається як:

дорогоцінний ;

Це особливо корисно для дозволу поступового оновлення бібліотек або налагодження
інформаційні файли, які кожен раз оновлюються, а не перебудовуються заново. Мінуси все одно залишаться
видаляти файли, коли вказано прапор `-r'.

Команда `Команда' метод

Метод `Command' є методом catchall, який можна використовувати для організації будь-якого зовнішнього
команда, яка буде викликана для оновлення цілі. Для цієї команди цільовий файл і список
надаються вхідні дані. Крім того, командний рядок або рядки побудови надаються як a
string (цей рядок може мати кілька вбудованих команд, розділених символом new
лінії). "Команда" називається так:

Команда $env , , ;

Ціль залежить від списку вказаних вхідних файлів, і вхідні дані повинні бути обов’язковими
буде створено успішно, або мінуси не намагатимуться побудувати ціль.

Усередині команди конструювання може бути будь-яка змінна із середовища конструювання
вводиться шляхом додавання до імені змінної конструкції префіксом `%'. Це рекурсивно:
команда розгортається до тих пір, поки не можна буде робити заміни. Якщо конструкція
змінна не визначена в середовищі, тоді буде замінено нульовий рядок. А
подвоєне `%%' буде замінено на один `%' в команді побудови.

Є кілька псевдозмінних, які також будуть розширені:

%> Ім'я цільового файлу (у багатоцільовій команді це завжди перша мета
згадано).

%0 Те саме, що `%>'.

%1, %2, ..., %9
Вони відносяться до вхідних файлів з першого по дев’ятий відповідно.

%< Повний набір вхідних даних. Якщо будь-який з них використовувався де-небудь ще в
поточного командного рядка (через `%1', `%2' тощо), тоді вони будуть видалені з
список, наданий `%<'. Розглянемо таку команду, знайдену в a Призовник файл
в тест каталог:

Команда $env 'tgt', qw(foo bar baz), qq(
луна %< -i %1 > %>
луна %< -i %2 >> %>
луна %< -i %3 >> %>
);

If tgt потрібно оновити, то це призведе до виконання
наступні команди, припускаючи, що перепризначення не було встановлено для тест
каталог:

echo test/bar test/baz -i test/foo > test/tgt
echo test/foo test/baz -i test/bar >> test/tgt
echo test/foo test/bar -i test/baz >> test/tgt

За будь-якою з наведених вище псевдозмінних може відразу слідувати одна з наступних
суфікси для вибору частини розгорнутого імені шляху:

:a абсолютний шлях до імені файлу
:b каталог плюс ім'я файлу без будь-якого суфікса
:d каталог
:f ім'я файлу
:s суфікс імені файлу
:F ім'я файлу позбавлене будь-якого суфікса

Продовжуючи наведений вище приклад, `%<:f' розгорнеться до `foo bar baz', а `%':d>
розгорнути до `test'.

Можна програмно переписати частину команди, охопивши її частину
між `%[' та `%]'. Це викличе змінну конструкції, названу першим словом
укладено в дужках як посилання на код Perl; будуть використані результати цього дзвінка
замінити вміст дужок у командному рядку. Наприклад, дано an
існуючий вхідний файл з ім tgt.in:

@keywords = qw(foo bar baz);
$env = new cons(X_COMMA => sub { join(",", @_) });
Команда $env 'tgt', 'tgt.in', qq(
echo '# Ключові слова: %[X_COMMA @keywords %]' > %>
кіт %< >> %>
);

Це виконає:

echo '# Ключові слова: foo,bar,baz' > tgt
cat tgt.in >> tgt

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

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

Зазвичай, якщо всі команди виконуються успішно і повертають нульовий статус (або будь-яку іншу платформу-
потрібна конкретна вказівка ​​успіху), тоді новий підпис зберігається для
ціль. Якщо команда помилково повідомляє про успіх навіть після невдачі, то мінуси
припустимо, що цільовий файл, створений цією командою, є точним і сучасним.

Перше слово кожного командного рядка після розширення вважається виконуваним
команда шукала змінну середовища `PATH' (яка, у свою чергу, вказується в
Конструкційна змінна `ENV'). Якщо цю команду знайдено на шляху, то ціль буде
залежати від цього: команда буде автоматично створена, якщо необхідно. Його
можна писати багатокомпонентні команди до деяких оболонок, розділених крапкою з комою. Тільки
Однак перше командне слово буде залежати від того, якщо ви напишете свої командні рядки
таким чином, ви повинні або явно налаштувати залежність (за допомогою методу `Depends'), або
переконайтеся, що команда, яку ви використовуєте, є системною командою, якою очікується
доступний. Якщо він недоступний, ви, звичайно, отримаєте повідомлення про помилку.

Якщо будь-яка команда (навіть одна в багаторядковій команді) починається з `[perl]', решта
цього командного рядка буде оцінено запущеним Perl замість того, щоб бути роздвоєним
оболонка. Якщо під час розбору Perl виникає помилка або вираз Perl повертає 0 або
undef, команда буде вважатися невиконаною. Наприклад, ось простий
команда, яка створює файл `foo' безпосередньо з Perl:

$env = нові мінуси ();
Команда $env 'foo',
qq([perl] open(FOO,'>foo');друк FOO "hi\\n"; close(FOO); 1);

Зауважте, що коли команда виконується, ви перебуваєте в тому ж пакеті, що й під час виконання Конструкція
or Призовник файл був прочитаний, тож ви можете викликати функції Perl, які ви визначили в тому самому
Конструкція or Призовник файл, у якому з'являється "Команда":

$env = нові мінуси ();
sub create_file {
мій $file = shift;
відкрити(FILE, ">$файл");
надрукувати FILE "hi\n";
закрити (ФАЙЛ);
1 повернутися;
}
Команда $env 'foo', "[perl] &create_file('%>')";

Рядок Perl буде використовуватися для створення підпису для похідного файлу, тому якщо ви
змініть рядок, файл буде перебудований. Вміст будь-яких підпрограм, які ви викликаєте,
однак вони не є частиною підпису, тому, якщо ви змінюєте викликану підпрограму, наприклад
`create_file' вище, ціль буде НЕ бути перебудованим. Застереження користувача.

Cons зазвичай друкує команду перед її виконанням. Ця поведінка пригнічується, якщо
перший символ команди — `@'. Зауважте, що вам може знадобитися відокремити `@' від
назву команди або екрануйте її, щоб запобігти тому, щоб `@cmd' виглядав як масив у лапках Perl
оператори, які виконують інтерполяцію:

# Перший командний рядок неправильний,
# тому що "@cp" виглядає як масив
# до функції Perl qq//.
# Натомість використовуйте другу форму.
Команда $env 'foo', 'foo.in', qq(
@cp %< tempfile
@ cp tempfile %>
);

Якщо де-небудь у розгорнутому командному рядку є метасимволи оболонки, наприклад "<",
`>', лапки або крапку з комою, тоді команда буде фактично виконана шляхом виклику
оболонка. Це означає, що така команда, як:

компакт-диск foo

сам по собі зазвичай зазнає невдачі, оскільки на шляху немає команди `cd'. Але команда
рядок:

cd $<:d; tar cf $>:f $<:f

при розгортанні все ще міститиме метасимвол оболонки крапка з комою, а оболонка буде
викликається для інтерпретації команди. Оскільки `cd' інтерпретується цією підоболонкою, команда
виконуватиметься, як очікувалося.

Щоб вказати команду з кількома цілями, можна вказати посилання на список
цілі. У Perl посилання на список можна створити, укладаючи список у квадратні дужки.
Звідси така команда:

Команда $env ['foo.h', 'foo.c'], 'foo.template', q(
покоління %1
);

можна використовувати у випадку, коли команда `gen' створює два файли, обидва foo.h та foo.c.

Команда `Об'єкти' метод

Метод `Objects' організовує створення об'єктних файлів, які відповідають заданому
вихідні файли. Він викликається, як показано нижче:

@files = Об'єкти $env ;

У Unix вихідні файли закінчуються на .s та .c наразі підтримуються та будуть скомпільовані
в ім’я того самого файлу, що закінчується на .o. За замовчуванням усі файли створюються шляхом виклику
зовнішня команда, яка є результатом розширення змінної конструкції `CCCOM', with
`%<' та `%>' встановлено для вихідних та об'єктних файлів відповідно (див. метод `Command'
для деталей розширення). Змінна `CPPPATH' також використовується під час сканування вихідних файлів
для залежностей. Це список імен шляхів, розділених двокрапкою, який також використовується для створення
конструкційну змінну `_IFLAGS', яка міститиме відповідний список -`I'
варіанти компіляції. Будь-які відносні імена шляху в `CPPPATH' інтерпретуються як відносні
до каталогу, в якому було створено пов’язане середовище конструювання (абсолютне
а також можуть використовуватися найвищі родичі). Цю змінну використовує `CCCOM'. Поведінка
цієї команди можна змінити, змінивши будь-яку зі змінних, які інтерполюють
в `CCCOM', наприклад `CC', `CFLAGS' і, опосередковано, `CPPPATH'. Це також можливо
замінити само значення `CCCOM'. Для зручності цей файл повертає список
імена файлів об'єктів.

Команда `Програма' метод

Метод `Program' організовує зв'язування вказаної програми із зазначеним об'єктом
файли. Його викликають у такий спосіб:

Програма $env , ;

До імені програми буде додано значення конструкційної змінної `SUFEXE' (by
за замовчуванням, `.exe' в системах Win32, нічого в системах Unix), якщо суфікс ще не вказано
присутній

Вихідні файли можуть бути вказані замість файлів об'єктів - буде метод `Objects'
викликається, щоб організувати перетворення всіх файлів в об’єктні файли, а отже, і всіх файлів
Спостереження щодо методу "Об'єкти", наведені вище, також стосуються цього методу.

Фактичне зв’язування програми буде оброблятися зовнішньою командою, яка в результаті
від розширення конструкційної змінної `LINKCOM', при цьому `%<' встановлено для об’єктних файлів до
бути пов’язаним (у представленому порядку), а `%>' встановлено на цільове значення (див. метод `Command'
для деталей розширення). Користувач може встановлювати додаткові змінні в конструкції
середовище, включаючи `LINK', щоб визначити, яку програму використовувати для зв'язування, `LIBPATH',
розділений двокрапкою список шляхів пошуку бібліотеки для використання зі специфікаціями бібліотеки
форма -lib, і `LIBS', вказуючи список бібліотек, з якими потрібно зв'язатися (в будь-якому з них -lib
форму або просто як шляхи. Інтерпретуються відносні імена шляху в `LIBPATH' і `LIBS'
відносно каталогу, в якому створено пов’язане середовище конструювання
(можуть також використовуватися абсолютні та відносні назви). Мінуси встановлюється автоматично
залежності від будь-яких бібліотек, згаданих у `LIBS': ці бібліотеки будуть створені раніше
команда пов'язана.

Команда `Бібліотека' метод

Метод «Бібліотека» організовує створення вказаної бібліотеки із зазначеного об’єкта
файли. Викликається наступним чином:

Бібліотека $env , ;

До імені бібліотеки буде додано значення змінної конструкції `SUFLIB' (by
за замовчуванням, `.lib' у системах Win32, `.a' в системах Unix), якщо суфікс ще не вказано
присутній

Вихідні файли можуть бути вказані замість файлів об'єктів - буде метод `Objects'
викликається, щоб організувати перетворення всіх файлів в об’єктні файли, а отже, і всіх файлів
Спостереження щодо методу "Об'єкти", наведені вище, також стосуються цього методу.

Фактичне створення бібліотеки буде здійснюватися за допомогою зовнішньої команди, яка в результаті
від розширення конструкційної змінної `ARCOM' з `%<' встановленим для членів бібліотеки (в
представленому порядку) і `%>' до бібліотеки, яка буде створена (див. метод `Command' для
деталі розширення). Користувач може встановлювати змінні в середовищі побудови, які будуть
впливати на роботу команди. До них відноситься `AR', програма-архів для використання,
`ARFLAGS', який можна використовувати для зміни прапорів, заданих програмі, визначеній `AR',
і `RANLIB', ім'я програми генерації індексу архіву, якщо необхідно (якщо ок
need не вимагає останньої функціональності, тоді `ARCOM' потрібно перевизначити, щоб не використовувати
посилання "RANLIB").

Метод «Бібліотека» дозволяє вказувати одну і ту ж бібліотеку в кількох методах
заклики. Усі допоміжні об’єкти з усіх викликів (які можуть бути від
різні каталоги) об’єднуються та генеруються однією командою архіву. Примітка,
однак, якщо ви обрізаєте збірку так, щоб була вказана лише частина бібліотеки, то лише
ця частина бібліотеки буде створена (решта зникне!).

Команда `Модуль' метод

Метод «Модуль» є комбінацією методів «Програма» та «Команда». Замість
безпосередньо генеруючи виконувану програму, ця команда дозволяє вказати власну
команду для фактичного створення модуля. Метод викликається наступним чином:

Модуль $env , , ;

Ця команда корисна в тих випадках, коли ви хочете створювати, наприклад, динамічно
завантажені модулі або статично пов’язані бібліотеки коду.

Команда `Залежить' метод

Метод `Depends' дозволяє вам вказати додаткові залежності для цілі. це є
викликається таким чином:

Залежить від $env , ;

Це іноді може бути корисним, особливо у випадках, коли сканера немає (або є
доступний для запису) для певних типів файлів. Як правило, розраховуються залежності
автоматично з комбінації явних залежностей, встановлених методом
виклик або сканування вихідних файлів.

Набір ідентичних залежностей для кількох цілей можна вказати за допомогою посилання на
список цілей. У Perl посилання на список можна створити, укладаючи список у квадрат
дужки. Звідси така команда:

Залежить від $env ['foo', 'bar'], 'input_file_1', 'input_file_2';

вказує, що обидва Foo та бар файли залежать від перелічених вхідних файлів.

Команда `ігнорувати' метод

Метод `Ignore' дозволяє вам явно ігнорувати залежності, які Cons виводить з його
власний. Викликається наступним чином:

Ігнорувати ;

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

Якщо, наприклад, програма вбудована в каталог, змонтований NFS, у кількох системах, які
мають різні копії stdio.h, відмінності вплинуть на підписи всіх
похідні цілі, створені з вихідних файлів, які `#include '. Це викличе все
ці цілі, які потрібно перебудувати при зміні систем. Якщо це не бажана поведінка,
тоді наступний рядок видалить залежності від stdio.h Файл:

Ігноруйте '^/usr/include/stdio\.h$';

Зауважте, що аргументи методу `Ignore' є регулярними виразами, тому особливі
символи повинні бути екрановані, і ви можете закріпити початок або кінець
вираз із символами `^' або `$'.

Команда `Сіль' метод

Метод «Сіль» додає постійне значення до обчислення сигнатури для кожного похідного
файл. Викликається наступним чином:

Сіль $string;

Зміна значення Salt призведе до повного відновлення кожного похідного файлу. Це може бути
використовується для примусової перебудови за певних бажаних обставин. Наприклад,

Сіль `uname -s`;

Змусить повністю перебудувати кожен похідний файл щоразу, коли операційна система буде ввімкнена
які виконується збірка (як повідомляє `uname -s') змінюється.

Команда `Використовувати кеш' метод

Метод `UseCache' інструктує Cons підтримувати кеш похідних файлів, які будуть ділитися
серед окремих будівельних дерев одного проекту.

UseCache("cache/ ") ⎪⎪ warn("каталог кешу не знайдено");

Команда `SourcePath' метод

Метод "SourcePath" повертає справжнє ім'я вихідного шляху до файлу, на відміну від
ім'я шляху в каталозі збірки. Викликається наступним чином:

$path = вихідний шлях ;

Команда `ConsPath' метод

Метод ConsPath повертає значення true, якщо наданий шлях є похідним файлом, і повертає
undef (false) інакше. Викликається наступним чином:

$result = ConsPath ;

Команда `SplitPath' метод

Метод `SplitPath' шукає декілька імен шляхів у рядку, розділених за замовчуванням
роздільник шляхів для операційної системи (':' в системах UNIX, ';' в Windows NT) і
повертає повні імена. Викликається наступним чином:

@paths = SplitPath ;

Метод «SplitPath» перетворить імена з префіксом «#» у відповідну збірку верхнього рівня
name (без '#') і перетворить відносні імена в імена верхнього рівня.

Команда `DirPath' метод

Метод `DirPath' повертає шлях збірки ім'я(s) каталогу або списку каталогів.
Викликається наступним чином:

$cwd = DirPath ;

Найбільш поширеним використанням методу `DirPath' є:

$cwd = DirPath '.';

щоб отримати шлях до поточного каталогу дочірньої компанії Призовник файлу.

Команда `FilePath' метод

Метод `FilePath' повертає шлях збірки ім'я(s) файлу або списку файлів. це є
викликається таким чином:

$file = Шлях до файлу ;

Команда `Допомога' метод

Метод `Help' визначає текст довідки, який буде відображатися, коли користувач викликає `cons
-h'. Це можна використовувати для забезпечення документації конкретних цілей, значень, збірки
параметри тощо для дерева побудови. Викликається наступним чином:

Допоможіть ;

Метод `Help' може бути викликаний лише один раз, і зазвичай його слід вказувати у верхній частині сторінки.
рівень Конструкція файлу.

Розширення мінуси

Переважаючий будівництво змінні

Існує кілька способів розширення мінусів, які відрізняються за ступенем складності. Найпростіший
метод полягає у визначенні вашого власного середовища будівництва на основі середовища за замовчуванням,
але змінено, щоб відображати ваші конкретні потреби. Цього часто буде достатньо для C-based
додатків. Ви можете використовувати конструктор `new', а також методи `clone' і `copy' для
створювати гібридні середовища. Ці зміни можуть бути абсолютно прозорими для основного
Призовник файли.

Додавання new методика

Для дещо більш вимогливих змін ви можете додати нові методи до «мінусів»
пакет. Ось приклад дуже простого розширення `InstallScript', яке встановлює a
tcl у потрібному місці, але спочатку редагує сценарій, щоб відобразити платформу-
залежний шлях, який необхідно встановити в скрипті:

# мінуси::InstallScript - Створіть залежну від платформи версію оболонки
# сценарій, замінивши рядок ``#!your-path-here'' на спеціальний для платформи
# шлях $BIN_DIR.

під мінуси::InstallScript {
my ($env, $dst, $src) = @_;
Команда $env $dst, $src, qq(
sed s+your-path-here+$BIN_DIR+ %< > %>
chmod oug+x %>
);
}

Зверніть увагу, що цей метод визначається безпосередньо в пакеті `cons' (за допомогою префікса імені
з `мінуси::'). Зміна, внесена таким чином, буде глобально видима для всіх середовищ,
і може називатися як у наступному прикладі:

InstallScript $env "$BIN/foo", "foo.tcl";

Для невеликого покращення загального характеру змінну `BINDIR' можна передати як
аргумент або взятий із середовища конструювання - як `%BINDIR'.

Переважаючий методика

Замість того, щоб додавати метод до простору імен `cons', ви можете визначити новий пакет
який успадковує існуючі методи з пакета `cons' і замінює або додає інші. Це
можна зробити за допомогою механізмів успадкування Perl.

Наступний приклад визначає новий пакет `cons::switch', який замінює стандарт
Метод «Бібліотека». Перевизначений метод створює зв’язані бібліотечні модулі, а не бібліотеку
архіви. Надається новий конструктор. Середовища, створені за допомогою цього конструктора, будуть
мати новий метод бібліотеки; інші не будуть.

мінуси пакета::перемикач;
ПОЧАТОК {@ISA = 'мінуси'}

під новий {
зміна;
благослови нові мінуси (@_);
}

підбібліотека {
my($env) = зсув;
my($lib) = зсув;
my(@objs) = Об'єкти $env @_;
Команда $env $lib, @objs, q(
%LD -r %LDFLAGS %< -o %>
);
}

Цю функціональність можна викликати, як у наступному прикладі:

$env = нові мінуси::switch(@overrides);
...
Бібліотека $env 'lib.o', 'foo.c', 'bar.c';

Викликаючи мінуси

Команда `cons' зазвичай викликається з кореня дерева збірки. А Конструкція файл
має існувати в цьому каталозі. Якщо використовується аргумент `-f', то альтернативний Конструкція
можна використовувати файл (і, можливо, альтернативний кореневий файл, оскільки `cons' буде cd Конструкція
файл, що містить каталог).

Якщо `cons' викликається з дочірнього кореня дерева збірки з аргументом `-t', це
підніметься вгору по ієрархії каталогів, шукаючи a Конструкція файл. (Можна альтернативна назва
все ще вказується за допомогою `-f'.) Цілі, надані в командному рядку, будуть змінені
бути відносним до виявленого Конструкція файл. Наприклад, з каталогу, що містить
верхнього рівня Конструкція файл, такий виклик:

% cd libfoo/підкаталог
% cons -t ціль

еквівалентно:

% мінусів libfoo/subdir/target

Якщо в ієрархії каталогів вказано цілі `за замовчуванням' Конструкція or
Призовник файли, лише цільові значення за замовчуванням на або нижче каталогу, з якого `cons -t'
був викликаний буде побудовано.

Команда викликається наступним чином:

мінуси --

де аргументація може бути будь-яким із наступних у будь-якому порядку:

мета Побудуйте вказану ціль. Якщо мета є каталогом, потім рекурсивно збирається
все в цьому каталозі.

+візерунок Обмежити Призовник файли розглядаються як лише ті, що відповідають модель, Яка є
регулярний вираз Perl. Приймаються кілька аргументів "+".

ім'я=
набори ім'я оцінювати Val у хеші `ARG' передається на верхній рівень Конструкція файлу.

`-cc' Показати команду, яка була б виконана під час отримання з кешу. Немає
вказується, що файл було отримано; це корисно для
створення журналів побудови, які можна порівняти з реальними журналами побудови.

`-cd' Вимкнути все кешування. Не отримувати з кешу і не очищати в кеш.

`-cr' Створюйте залежності у випадковому порядку. Це корисно при створенні кількох
подібні дерева з увімкненим кешуванням.

`-cs' Синхронізувати наявні цілі збірки, які виявлено оновленими з кеш-пам'яттю.
Це корисно, якщо кешування було вимкнено за допомогою -cc або нещодавно ввімкнено
з UseCache.

`-d' Увімкнути налагодження залежностей.

`-f'
Використовуйте вказаний файл замість Конструкція (але спочатку змініть на що містить
каталог файл).

`-h' Показати довідкове повідомлення, локальне для поточної збірки, якщо таке визначено, і вийти.

`-k' Продовжуйте йти якомога далі після помилок.

`-o'
Прочитати файл заміни файл.

`-p' Показати будівельні продукти у визначених деревах. Спроба побудови не проводиться.

`-pa' Показує будівельні продукти та пов'язані з ними дії. Спроба побудови не проводиться.

`-pw' Показати продукти та де вони визначені. Спроба побудови не проводиться.

`-q' Не будьте багатослівними про встановлення та видалення цілей.

`-r' Видалити будівельні продукти, пов'язані з . Спроба побудови не проводиться.

`-R'
Пошук файлів у відпочинок. Кілька -R відпочинок пошук у каталогах здійснюється в
вказано порядок.

`-t' Перехід по ієрархії каталогів у пошуках a Конструкція файл, якщо такий не існує
у поточному каталозі. Цілі будуть змінені відповідно до
Конструкція файлу.

`-v' Показати версію мінусів і продовжити обробку.

`-V' Показати версію з мінусами та вийти.

`-wf'
Запишіть усі розглянуті імена файлів файл.

`-x' Показати довідкове повідомлення, подібне до цього, і вийти.

і construct-args можуть бути будь-які аргументи, які ви хочете обробити в Конструкція файлу.
Зауважте, що має бути a -- розділяючи аргументи на мінуси та аргументи, які ви
бажаючи обробити в Конструкція файлу.

Обробка construct-args можна зробити будь-яким стандартним пакетом, наприклад Getopt або його
варіанти або будь-який визначений користувачем пакет. мінуси пройде в construct-args as @ARGV та
не намагатиметься щось інтерпретувати після --.

% cons -R /usr/local/repository -d os=solaris +driver -- -c test -f НАЛАДЖЕННЯ

передає наступне до мінусів

-R /usr/local/repository -d os=solaris +драйвер

і наступне, на верхній рівень Конструкція файл як @ARGV

-c тест -f НАЛАДЖЕННЯ

Зверніть увагу, що `cons -r .' еквівалентно повному рекурсивному `make clean', але не вимагає
підтримка в Конструкція файл або будь -який інший Призовник файли. Це найбільш корисно, якщо ви є
компіляція файлів у вихідні каталоги (якщо ви відокремлюєте файл будувати та експорт каталоги,
тоді ви можете просто видалити каталоги).

Параметри `-p', `-pa' та `-pw' надзвичайно корисні для використання в якості допомоги при читанні
сценаріїв або їх налагодження. Якщо ви хочете знати, який скрипт встановлюється export/include/foo.h,
наприклад, просто введіть:

% мінусів -pw export/include/foo.h

використання та лист залежність сканери

QuickScan дозволяє налаштувати прості незалежні від цілі сканери для вихідних файлів. Тільки
один сканер QuickScan може бути пов'язаний з будь-яким вихідним файлом і середовищем.

QuickScan викликається наступним чином:

QuickScan CONSENV CODEREF, FILENAME [, PATH]

Очікується, що підпрограма, на яку посилається CODEREF, поверне список включених імен файлів
безпосередньо через FILE. Ці імена файлів, у свою чергу, будуть перевірені. Необов’язковий аргумент PATH
надає шлях пошуку для пошуку FILENAME та/або файлів, повернутих користувачем
підпрограма. PATH може бути посиланням на масив імен каталогів пошуку, або a
рядок імен, розділених системним символом роздільника (':' у системах UNIX, ';' на
Windows NT).

Підпрограма викликається один раз для кожного рядка у файлі, при цьому $_ встановлюється на поточний рядок.
Якщо підпрограмі потрібно переглянути додаткові рядки або, якщо на те пішло, весь файл,
тоді він може прочитати їх самостійно з дескриптора файлу SCAN. Він також може завершити цикл, якщо
він знає, що подальша інформація про включення недоступна, закриваючи дескриптор файлу.

Незалежно від того, надано шлях пошуку чи ні, QuickScan спочатку намагається знайти файл
відносно поточного каталогу (для файлу верхнього рівня, що надається безпосередньо в QuickScan),
або з каталогу, що містить файл, який посилається на файл. Це не дуже
загалом, але здається досить хорошим – особливо якщо у вас є розкіш написати свій власний
утиліт і може контролювати використання шляху пошуку стандартним способом. Нарешті,
шлях пошуку наразі розділений двокрапкою. Це може не зробити табір NT щасливим.

Ось реальний приклад, взятий з a Конструкція файл тут:

під мінуси::SMFgen {
my($env, @tables) = @_;
foreach $t (@tables) {
$env->QuickScan(sub { /\b\S*?\.smf\b/g }, "$t.smf",
$env->{SMF_INCLUDE_PATH});
$env->Command(
["$t.smdb.cc","$t.smdb.h","$t.snmp.cc","$t.ami.cc", "$t.http.cc"],
"$t.smf",
q(
smfgen %( %SMF_INCLUDE_OPT %) %
)
);
}
}

[ЗАУВАЖІТЬ, що форми `$env->QuickScan...' та `$env->Command...' не повинні бути
необхідний, але з певних причин необхідний для цього конкретного виклику. Це з'являється
бути помилкою в Perl або непорозумінням з мого боку; цього стилю виклику немає
завжди видається необхідним.]

Це знаходить всі назви форми .smf у файлі. Він поверне імена, навіть якщо
їх можна знайти в коментарях, але це нормально (механізм прощає зайві файли;
вони просто ігноруються з припущенням, що відсутній файл буде помічено, коли
програма, у цьому прикладі, smfgen, фактично викликається).

Сканер викликається лише для даного вихідного файлу, якщо він потрібен якомусь цілі в
дерево. Він викликається лише один раз для даного вихідного файлу.

Ось ще один спосіб створити такий самий сканер. Тут використовується явне посилання на код,
а також (у цьому випадку без потреби) сам читає весь файл:

sub myscan {
мій(@включає);
робити {
push(@includes, /\b\S*?\.smf\b/g);
} поки ;
@включає
}

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

QuickScan $env \myscan, "$_.smf";

ПІДТРИМКА І ПРОПОЗИЦІЇ

Мінуси підтримується спільнотою користувачів. Щоб підписатися, надішліть лист на мінуси обговорити-
[захищено електронною поштою] з тілом підписуватися.

Будь ласка, повідомте про будь-які пропозиції через [захищено електронною поштою] список адресатів.

Використовуйте мінуси онлайн, використовуючи служби onworks.net