минусы - Интернет в облаке

ПРОГРАММА:

ИМЯ

Минусы - система построения программного обеспечения

ОПИСАНИЕ

Руководство и справочник для версии 2.2.0

Авторское право (c) 1996-2000 Free Software Foundation, Inc.

Эта программа является бесплатным программным обеспечением; вы можете распространять и / или изменять его в соответствии с условиями
Стандартная общественная лицензия GNU, опубликованная Free Software Foundation; или
версия 2 лицензии или (по вашему выбору) любая более поздняя версия.

Эта программа распространяется в надежде, что она будет полезна, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ;
даже без подразумеваемых гарантий ТОВАРНОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.
Подробнее см. Стандартную общественную лицензию GNU.

Вы должны были получить копию Стандартной общественной лицензии GNU вместе с этой программой;
см. файл КОПИРОВАНИЕ. Если нет, напишите в Free Software Foundation, Inc., 59 Temple.
Место - Suite 330, Бостон, Массачусетс 02111-1307, США.

Введение

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

Cons использует ряд методов для достижения всего этого. Строительные скрипты просто
Сценарии Perl, что делает их простыми для понимания и очень гибкими. Глобальное исследование
переменные заменены механизмом импорта / экспорта для обмена информацией между
скрипты, значительно улучшающие читаемость и ремонтопригодность каждого скрипта.
Строительство средах представлены: это объекты Perl, которые захватывают
информация, необходимая для управления процессом сборки. Используются несколько сред
когда для создания продуктов в дереве сборки требуется другая семантика. Минусы
реализует автоматический анализ зависимостей и использует его для глобального упорядочивания всего
строить. Варианты сборки легко создаются из единого дерева исходных текстов. Интеллектуальная сборка
подмножество возможно при работе над локализованными изменениями. Переопределения можно настроить на
легко переопределять инструкции сборки без изменения каких-либо сценариев. Криптографический MD5
подписей связаны с производными файлами и используются для точного определения того,
данный файл необходимо перестроить.

Предлагая все вышеперечисленное и многое другое, Cons остается простым и легким в использовании. Это будет,
надеюсь, станет ясно, когда вы прочитаете оставшуюся часть этого документа.

почему Минусы? почему не Сделать?

Минусы - это сделать замена. В следующих абзацах мы рассмотрим несколько
нежелательные характеристики производителя - и типичные среды сборки, основанные на make, - которые
мотивировал развитие Cons.

строить сложность

Традиционные системы на основе make любого размера, как правило, становятся довольно сложными. Оригинальная марка
утилита и ее производные внесли свой вклад в эту тенденцию разными способами. Сделать это
плохо справляется с системами, которые разбросаны по нескольким каталогам. Различная работа-
окружающие используются для преодоления этой трудности; обычно выбирается make для вызова
сам рекурсивно для каждого подкаталога сборки. Это приводит к сложному коду в
из-за чего часто неясно, как устанавливается переменная или как влияет установка переменной
придется на сборку в целом. Язык сценариев make постепенно расширялся.
чтобы предоставить больше возможностей, но они в значительной степени служат для того, чтобы загромождать уже
чрезмерно растянутый язык. Часто сборки выполняются за несколько проходов, чтобы обеспечить
соответствующие продукты из одного каталога в другой каталог. Это представляет собой дальнейшее
увеличение сложности сборки.

строить воспроизводимость

Проклятием всех производителей всегда было правильное обращение с зависимостями. Чаще всего
делается попытка сделать разумную работу с зависимостями в пределах одного каталога, но нет
предпринята серьезная попытка сделать работу между каталогами. Даже когда зависимости
работает правильно, полагайтесь на простое сравнение отметок времени, чтобы определить,
файл устарел в отношении его иждивенцев, как правило, не подходит для
определение того, когда файл следует повторно создать. Если, например, внешняя библиотека
перестроен, а затем `` прикреплен '' к месту, временные метки на его вновь созданных файлах могут
хорошо быть раньше, чем последняя локальная сборка, поскольку она была построена до того, как стала видимой.

Вариант строит

Make предоставляет только ограниченные возможности для обработки вариантных сборок. С распространением
аппаратных платформ и потребность в отлаживаемом и оптимизированном коде, возможность
легко создавать эти варианты. Что еще более важно, если варианты созданы, это
важно либо уметь разделять варианты, либо уметь воспроизводить
оригинал или вариант по желанию. С помощью make очень сложно разделить сборки на
несколько каталогов сборки, отдельных от источника. И если этот прием не используется,
также практически невозможно гарантировать в любой момент времени, какой вариант присутствует в
дерево, не прибегая к полной перестройке.

Хранилища

Make предоставляет только ограниченную поддержку для создания программного обеспечения из кода, существующего в
структура каталогов центрального репозитория. Функция VPATH в GNU make (и некоторых других
make реализация) предназначен для этого, но работает не так, как ожидалось: он
изменяет путь к целевому файлу на имя VPATH слишком рано в своем анализе, и, следовательно,
ищет все зависимости в каталоге VPATH. Для правильного развития
сборки, важно иметь возможность создать файл в локальном каталоге сборки и иметь
любые файлы в репозитории кода (каталог VPATH, в терминах make), которые зависят от локального
файл будет восстановлен правильно. Это невозможно с VPATH без большого количества кодов.
комплексные знания о репозитории прямо в make-файлы.

Хранение it декриминализовано

Некоторые трудности с make были упомянуты выше. В этом и последующих
В разделах мы расскажем о минусах и покажем, как эти проблемы решаются.

Perl скрипты

Минусы основаны на Perl. То есть скрипты Cons -призывник и Строить файлы, эквивалент
в Makefile or Makefile- все написаны на Perl. Это дает немедленную выгоду:
язык для написания скриптов - знакомый. Даже если вы не являетесь Perl
программист, полезно знать, что Perl - это в основном простой декларативный язык,
с четко определенным потоком управления и знакомой семантикой. У него есть переменные, которые ведут себя
в основном так, как вы ожидаете, подпрограммы, поток управления и так далее. Там
Для Cons не введен специальный синтаксис. Использование Perl в качестве языка сценариев
упрощает задачу выражения подходящего решения для часто сложных
требования сборки.

Здравствуйте, Мир!

Чтобы обосновать следующее обсуждение, вот как вы могли бы построить Здравствуйте, Мир! C
приложение с минусами:

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

Если вы установите этот сценарий в каталог, присвоив ему имя Строить, и создайте
Привет исходный файл в том же каталоге, затем вы можете ввести `cons hello ', чтобы построить
Приложение:

% cons привет
cc -c привет.с -о привет.о
cc -o привет привет.о

Строительство средах

Ключевое упрощение Cons - идея строительство охрана окружающей среды. Строительство
окружающая среда объект характеризуется набором пар ключ / значение и набором методы.
Чтобы сообщить Cons, как что-то построить, вы вызываете соответствующий метод через
соответствующая строительная среда. Рассмотрим следующий пример:

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

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

В этом случае вместо того, чтобы использовать среду построения по умолчанию, как есть, мы имеем
переопределить значение `CC 'так, чтобы вместо него использовался эквивалент компилятора GNU C. С
эта версия Здравствуйте, Мир! требуется библиотека, libworld.a, мы указали, что любой
программа, связанная в этой среде, должна быть связана с этой библиотекой. Если библиотека
уже существует, ну и хорошо, но если нет, то нам также нужно будет включить оператор:

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

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

% cons привет
gcc -c привет.с -о привет.о
gcc -c мир.с -о мир.о
ar r libworld.a world.o
ar: создание libworld.a
ранлиб libworld.a
gcc -o привет hello.o libworld.a

Автоматический и полный зависимость анализ

С Cons зависимости обрабатываются автоматически. Продолжая предыдущий пример, обратите внимание
что когда мы изменяем мир.c, мир.о перекомпилирован, libworld.a воссоздан, и Здравствуйте
переподключено:

% vi мир.c
[РЕДАКТИРОВАТЬ]
% cons привет
gcc -c мир.с -о мир.о
ar r libworld.a world.o
ar: создание libworld.a
ранлиб libworld.a
gcc -o привет hello.o libworld.a

Это относительно простой пример: Минусы `` знает '' мир.о зависит от мир.c, потому как
зависимость явно устанавливается методом `Library '. Он также знает, что libworld.a
зависит от мир.о и что Здравствуйте зависит от libworld.a, все по схожим причинам.

Теперь выясняется, что Привет также включает файл определения интерфейса, мир.ч:

% emacs world.h
[РЕДАКТИРОВАТЬ]
% cons привет
gcc -c привет.с -о привет.о
gcc -o привет hello.o libworld.a

Откуда Cons знает, что Привет включает в себя мир.ч, И что привет.о поэтому должно быть
перекомпилировал? А пока достаточно сказать, что при рассмотрении вопроса о том, привет.о вверх-
на сегодняшний день Cons вызывает сканер своей зависимости, Привет. Этот сканер перечисляет
файлы, включенные Привет составить список дальнейших зависимостей, помимо тех
сделано явным сценарием Cons. Этот процесс рекурсивен: любые файлы, включенные
включенные файлы также будут проверены.

Разве это не дорого? Ответ - это зависит от обстоятельств. Если вы делаете полную сборку большой системы,
время сканирования незначительное. Если вы сделаете перестройку большой системы, то Минусы будут
потратьте немало времени на размышления об этом, прежде чем он решит, что ничего не должно быть
сделано (хотя не обязательно больше времени, чем делать!). Хорошая новость в том, что Cons делает это
очень легко интеллектуально подгруппировать вашу сборку, когда вы работаете над локализованными изменениями.

Автоматический Глобальный строить последовательность действий

Поскольку Cons выполняет полный и точный анализ зависимостей, причем глобально, для
всю сборку, Cons может использовать эту информацию, чтобы получить полный контроль над последовательность действий
сборки. Эта последовательность очевидна в приведенных выше примерах и эквивалентна тому, что
вы ожидаете от make, учитывая полный набор зависимостей. С "Минусами" это расширяет
тривиально к более крупным сборкам с несколькими каталогами. В результате вся сложность
в обеспечении правильной организации сборки, включая многопроходную иерархическую
строит - устраняется. Мы обсудим это далее в следующих разделах.

Строительство большой деревья - еще всего as декриминализовано

A иерархия of строить скрипты

Более крупная сборка в Cons организована путем создания иерархии строить скрипты. На вершине
дерева - это скрипт, называемый Строить. Остальные скрипты условно каждый
под названием призывник. Эти скрипты очень просто связаны друг с другом при помощи `Build ',
Команды «Экспорт» и «Импорт».

Ассоциация строить команду

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

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

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

Это также можно было бы написать как многоуровневый скрипт. Например, Строить файл может
содержат эту команду:

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

и призывник подать в драйверы каталог может содержать это:

Сборка qw (
дисплей / призывник
мышь / призывник
);

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

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

Conscript_chdir 1;

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

Ожидается, что это поведение станет по умолчанию в некоторых будущих версиях Cons.
Чтобы подготовиться к этому переходу, сборки, которые ожидают, что Cons останутся на вершине сборки.
пока он читает в дочерней компании призывник файл должен явно отключить эту функцию как
следующим образом:

Conscript_chdir 0;

Относительный, верховный родственник, и абсолютный файл имена

Вы могли заметить, что имена файлов, указанные в команде Build, относятся к
расположение сценария, из которого он вызывается. Обычно это верно для другого имени файла
аргументы и для других команд, хотя мы могли бы также упомянуть здесь, что если вы начнете
имя файла с решеткой, `` # '', тогда этот файл интерпретируется относительно верхнего
каталог уровня (где Строить файл находится). И, что неудивительно, если начать
с `` / '', тогда это считается абсолютным путем. Это верно даже для систем
которые используют обратную косую черту вместо прямой для именования абсолютных путей.

. модули in строить скрипты

Вы можете вставлять модули в каждый призывник файл, используя обычный Perl `use 'или` require'
заявления:

использовать английский;
требуется My :: Module;

Каждое "использование" или "требование" влияет только на одно призывник файл, в котором он появляется. Чтобы использовать
модуль в нескольких призывник файлов, вы должны поместить оператор use или require в каждый
тот, которому нужен модуль.

Объем of переменные

На высшем уровне Строить файл и все призывник файлы начинают жизнь в общем, отдельном Perl
пакет. Минусы управляет таблицей символов для пакета, так что таблица символов для
каждый скрипт пуст, за исключением Строить файл, который получает часть командной строки
аргументы. Все переменные, которые устанавливаются или используются, поэтому устанавливаются скриптом.
сам - не каким-то внешним скриптом.

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

Ассоциация Экспортировать команду

Команда `Экспорт 'используется, как в следующем примере:

$ env = новые минусы ();
$ INCLUDE = "# экспорт / включение";
$ LIB = "# экспорт / библиотека";
Экспорт qw (env INCLUDE LIB);
Сборка qw (util / Conscript);

Значения простых переменных, упомянутых в списке «Экспорт», будут удалены.
любыми последующими командами `Build '. Команда `Export 'экспортирует только Perl скаляр
переменные, то есть переменные, имя которых начинается с символа `$ '. Другие переменные, объекты и т. Д.
можно экспортировать по ссылке - но все скрипты будут ссылаться на один и тот же объект, и это
объект должен рассматриваться как доступный только для чтения вспомогательными скриптами и исходным
экспортный скрипт. Однако допустимо присвоить новое значение экспортируемому скаляру.
переменная - это не изменит ссылочную базовую переменную. Эта последовательность для
пример, ОК:

$ env = новые минусы ();
Экспорт qw (env INCLUDE LIB);
Сборка qw (util / Conscript);
$ env = новые минусы (CFLAGS => '-O');
Сборка qw (другой / Призывник);

Не имеет значения, установлена ​​ли переменная до или после команды «Экспорт». В
важно значение переменной во время выполнения команды `Build '.
Это то, что убирают. Любые последующие команды `Export ', кстати,
сделать первый недействительным: вы должны указать все переменные, которые хотите экспортировать, на каждом
Команда `Экспорт '.

Ассоциация Импортировать команду

Переменные, экспортируемые командой `Экспорт ', могут быть импортированы во вспомогательные скрипты с помощью
Команда `Импорт '. Дополнительный скрипт всегда импортирует переменные непосредственно из
превосходный сценарий. Рассмотрим этот пример:

Импортировать qw (env INCLUDE);

Это допустимо только в том случае, если родительский сценарий экспортировал и `$ env ', и` $ INCLUDE'. Он также должен
дали значения каждой из этих переменных. Допускается использование вспомогательного скрипта только
импортировать подмножество экспортируемых переменных (в этом примере `$ LIB ', которое было экспортировано
предыдущий пример не импортируется).

Все импортированные переменные автоматически реэкспортируются, поэтому последовательность:

Импортировать qw (env INCLUDE);
Сборка qw (под мной / Призывник);

предоставит во вспомогательный файл и $ env, и $ INCLUDE. Если только `$ env 'должен быть
экспортировано, то достаточно будет:

Импортировать qw (env INCLUDE);
Экспорт в qw (env);
Сборка qw (под мной / Призывник);

Излишне говорить, что переменные могут быть изменены локально перед вызовом `Build 'на
вспомогательный сценарий.

строить скрипт оценка заказ

Единственное ограничение на порядок сценариев сборки состоит в том, что сценарии более высокого уровня
оцениваются раньше своих худших сценариев. На высшем уровне Строить файл, например,
сначала оценивается, а затем следуют любые неполноценные скрипты. Это все, что вам действительно нужно знать
о порядке оценки, так как порядок, как правило, не имеет значения. Рассмотрим следующие
Команда `Build ':

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

Мы решили расположить имена скриптов в алфавитном порядке просто потому, что это наиболее
удобен для технического обслуживания. Изменение порядка не повлияет на
строить.

A Модель для разделение файлов

Некоторые декриминализовано конвенций

В любой сложной программной системе метод обмена продуктами сборки должен быть
учредил. Мы предлагаем простой набор соглашений, которые легко реализовать с помощью
Минусы, но очень эффективны.

Основное правило - требовать, чтобы все продукты сборки, которые должны быть разделены между
каталоги совместно используются через промежуточный каталог. Обычно мы называем это
экспорт, а в среде C предоставляет обычные подкаталоги этого каталога,
как включают, Lib, бункер, и т.д.

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

# Создать файл для Hello, World!

# Где разместить все наши общие продукты.
$ EXPORT = '#export';

Экспорт qw (СОДЕРЖАНИЕ ВКЛЮЧИТЬ LIB BIN);

# Стандартные каталоги для обмена продуктами.
$ INCLUDE = "$ ЭКСПОРТ / включить";
$ LIB = "$ EXPORT / lib";
$ BIN = "$ ЭКСПОРТ / корзина";

# Стандартная строительная среда.
$ МИНУСЫ = новые минусы (
CPPPATH => $ INCLUDE, # Включить путь для компиляций C
LIBPATH => $ LIB, # Путь к библиотеке для компоновки программ
LIBS => '-lworld', # Список стандартных библиотек
);

Сборка qw (
привет / призывник
мир / Призывник
);

Ассоциация Мир каталог призывник файл выглядит так:

# Файл-призывник для каталога world
Импортировать qw (CONS INCLUDE LIB);

# Установить продукты из этого каталога
Установите $ CONS $ LIB, 'libworld.a';
Установите $ CONS $ INCLUDE, 'world.h';

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

и Здравствуйте каталог призывник файл выглядит так:

# Файл призывника для каталога hello
Импорт qw (CONS BIN);

# Экспортированных товаров
Установите $ CONS $ BIN, привет;

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

Чтобы построить Здравствуйте, Мир! программа с такой структурой каталогов, перейдите на верхний уровень
каталог и вызовите cons с соответствующими аргументами. В следующем примере мы
скажите Cons создать каталог экспорт. Для создания каталога Cons рекурсивно строит все
известные продукты в этом каталоге (конечно, только если они нуждаются в перестройке). Если любой из
эти продукты зависят от других продуктов в других каталогах, тогда они будут построены,
тоже.

% минусов на экспорт
Установите world / world.h как export / include / world.h
cc -Iexport / include -c hello / hello.c -o привет / hello.o
cc -Iexport / include -c world / world.c -o world / world.o
ar r мир / libworld.a мир / world.o
ar: создание мира / libworld.a
мир ранлиб / libworld.a
Установите world / libworld.a как export / lib / libworld.a
cc -o привет / привет привет / hello.o -Lexport / lib -lworld
Установите hello / hello как export / bin / hello

Чистый, понятно, независимый от местоположения скрипты

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

Также обратите внимание, как Cons заботится о мелких деталях за вас. Все экспорт каталоги, для
Например, были сделаны автоматически. И установленные файлы действительно жестко связаны с
соответствующие каталоги экспорта для экономии места и времени. Это внимание к деталям спасает
значительный объем работы и еще больше упрощает создание простых, поддерживаемых сценариев.

отделяющий источник и строить деревьям

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

отделяющий строить и источник каталоги через домен Ссылка команду

Cons предоставляет простой механизм, который удовлетворяет всем этим требованиям. Ссылка
команда вызывается, как в этом примере:

Ссылка 'build' => 'src';

Указанные каталоги `` связаны '' с указанным исходным каталогом. Предположим
что вы устанавливаете исходный каталог, SRC, с подкаталогами Мир и Здравствуйте под этим,
как в предыдущем примере. Затем вы можете заменить исходные линии построения на
следующие:

Сборка qw (
build / world / Призывник
build / hello / Призывник
);

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

% минусов на экспорт
Установите 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
сборка ранлиб / мир / 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 позаботился о деталях за вас. В частности, вы заметите, что все
сборки выполняются с использованием исходных файлов и объектных файлов из каталога сборки. За
пример, сборка / мир / world.o составлен из сборка / мир / world.cкачества
экспорт / включить / world.h устанавливается из построить / мир / world.h. Это достигается на большинстве
системы с помощью простого приема `` жесткого '' связывания требуемых файлов из каждого источника
каталог в соответствующий каталог сборки.

Ссылки правильно поддерживаются Cons, независимо от того, что вы делаете с исходным каталогом.
Если вы измените исходный файл, ваш редактор может сделать это `` на месте '' или переименовать его.
сначала и создайте новый файл. В последнем случае любая жесткая ссылка будет потеряна. Минусы будут
обнаружит это условие в следующий раз, когда понадобится исходный файл, и повторно свяжет его
соответственно.

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

Вариант строит

Здравствуйте, Мир! для банан и персик ОС

Для вариантов сборки требуется просто еще одно простое расширение. Возьмем для примера
Требование разрешить сборки для операционных систем baNaNa и peAcH. В таком случае,
мы используем распределенную файловую систему, такую ​​как NFS, для доступа к конкретной системе, и
только одна или другая из систем должна быть скомпилирована для любого конкретного вызова
"минусы". Вот один из способов настроить Строить файл для нашего Здравствуйте, Мир!
Приложение:

# Создать файл для Hello, World!

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

# Где разместить все наши общие продукты.
$ EXPORT = "# экспорт / $ OS";

Экспорт qw (СОДЕРЖАНИЕ ВКЛЮЧИТЬ LIB BIN);

# Стандартные каталоги для обмена продуктами.
$ INCLUDE = "$ ЭКСПОРТ / включить";
$ LIB = "$ EXPORT / lib";
$ BIN = "$ ЭКСПОРТ / корзина";

# Стандартная строительная среда.
$ МИНУСЫ = новые минусы (
CPPPATH => $ INCLUDE, # Включить путь для компиляций C
LIBPATH => $ LIB, # Путь к библиотеке для компоновки программ
LIBS => '-lworld', # Список стандартных библиотек
);

# $ BUILD - это то место, где мы получим все.
$ BUILD = "# сборка / $ OS";

# Сообщите минусам, где находятся исходные файлы для $ BUILD.
Ссылка $ BUILD => 'src';

Строить (
"$ BUILD / привет / Призывник",
"$ BUILD / мир / Призывник",
);

Теперь, если мы войдем в систему 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 / персик / мир / libworld.a сборка / персик / мир / world.o
ar: создание build / peach / world / libworld.a
сборка ранлиба / персик / мир / libworld.a
Установите build / peach / world / libworld.a как export / peach / lib / libworld.a
cc -o build / peach / hello / hello build / peach / hello / hello.o -Lexport / персик / lib -lworld
Установите build / peach / hello / hello как export / peach / bin / hello

Вариации on a тема

Возможны другие варианты этой модели. Например, вы можете решить, что хотите
для разделения ваших включаемых файлов на платформенно-зависимые и платформенно-независимые файлы.
В этом случае вам нужно будет определить альтернативу `$ INCLUDE 'для платформенно-зависимых
файлы. Большинство призывник файлы, генерирующие полностью независимые от платформы включаемые файлы, будут
менять не надо.

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

Подписи

MD5 криптографический подписей

Всякий раз, когда Cons создает производный файл, он сохраняет подпись для этого файла. Подпись
хранится в отдельном файле, по одному на каталог. После того, как предыдущий пример был скомпилирован,
домен .отправить подать в сборка / персик / мир каталог выглядел так:

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

Первое число - это отметка времени - для систем UNIX это обычно количество
секунд с 1 января 1970 года. Второе значение - контрольная сумма MD5. В Сообщение Digest
Алгоритм представляет собой алгоритм, который по входной строке вычисляет надежный криптографический
подпись для этой строки. Контрольная сумма MD5 хранится в .отправить файл, по сути,
дайджест всей информации о зависимостях для указанного файла. Так, например, для
мир.о файл, это включает как минимум мир.c файл, а также любые файлы заголовков, которые
знает о том, что прямо или косвенно включены мир.c, Не только это, но и
фактическая командная строка, которая использовалась для генерации мир.о также используется для вычисления
подпись. Так же, libworld.a получает подпись, которая `` включает '' все
подписи его составляющих (и, следовательно, транзитивно, подписи их
составляющие), а также командную строку, в которой был создан файл.

Подпись не производного файла по умолчанию вычисляется с использованием текущего
время модификации файла и имя записи файла (если только не
текущий .отправить запись для этого файла, и в этом случае используется эта подпись).

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

Когда Cons решает, следует ли получить конкретный файл, он сначала вычисляет
ожидаемая подпись файла. Затем он сравнивает время последней модификации файла с
время, записанное в .отправить запись, если таковая существует. Если эти времена совпадают, то
подпись хранится в .отправить файл считается точным. Если предыдущий файл
подпись не соответствует новой ожидаемой подписи, тогда файл необходимо заново создать.

Обратите внимание, что файл будет повторно создан всякий раз, когда что-либо в зависимом файле изменяется. В
в частности, обратите внимание, что любой изменить время модификации иждивенца (вперед или
назад во времени) вызовет перекомпиляцию производного файла.

Использование этих подписей - чрезвычайно простой, действенный и действенный метод
значительно улучшая воспроизводимость системы.

Продемонстрируем это на простом примере:

# Простое "Hello, World!" Создать файл
$ CFLAGS = '-g', если $ ARG {DEBUG} eq 'on';
$ CONS = новые минусы (CFLAGS => $ CFLAGS);
Программа $ CONS 'hello', 'hello.c';

Обратите внимание, как Cons перекомпилируется в нужное время:

% cons привет
cc -c привет.с -о привет.о
cc -o привет привет.о
% cons привет
минусы: "привет" актуально.
% cons DEBUG = привет
cc -g -c привет.с -о привет.о
cc -o привет привет.о
% cons DEBUG = привет
минусы: "привет" актуально.
% cons привет
cc -c привет.с -о привет.о
cc -o привет привет.о

Code Хранилища

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

вместилище

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

Следующие строки в Строить файл проинструктирует Cons сначала заглянуть под
/ usr / эксперимент / репозиторий каталог, а затем в / usr / продукт / репозиторий каталог:

Репозиторий qw (
/ usr / эксперимент / репозиторий
/ usr / продукт / репозиторий
);

Указанные каталоги репозитория могут содержать исходные файлы, производные файлы (объекты,
библиотеки и исполняемые файлы) или и то, и другое. Если нет локального файла (исходного или производного) в
каталог, в котором выполняется Cons, затем найдена первая копия файла с таким же именем
в каталоге репозитория будет использоваться для создания любых локальных производных файлов.

Cons поддерживает один глобальный список каталогов репозиториев. Минусы устранят
текущий каталог и любые несуществующие каталоги из списка.

Обнаружение домен Строить файл in a вместилище

Минусы тоже буду искать Строить и призывник файлы в дереве или деревьях репозитория.
Однако это приводит к ситуации «курица и яйцо»: как вы выглядите в дереве репозитория?
для Строить файл, если Строить файл сообщает вам, где находится репозиторий? Получить
вокруг этого репозитории могут быть указаны с помощью опции -R в командной строке:

% cons -R / usr / эксперимент / репозиторий -R / usr / продукт / репозиторий.

Любые каталоги репозитория, указанные в Строить or призывник файлы будут добавлены
в каталоги репозитория, указанные параметрами командной строки `-R '.

вместилище источник файлов

Если исходный код (включите призывник файл) для библиотечной версии Здравствуйте,
Мир! Приложение C находится в репозитории (без производных файлов), Cons будет использовать
исходные файлы репозитория для создания локальных объектных файлов и исполняемого файла:

% cons -R / usr / src_only / репозиторий привет
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
ранлиб libworld.a
gcc -o привет hello.o libworld.a

Создание локального исходного файла заставит Cons перестроить соответствующий производный файл или
файлов:

% пико мир.c
[РЕДАКТИРОВАТЬ]
% cons -R / usr / src_only / репозиторий привет
gcc -c мир.с -о мир.о
ar r libworld.a world.o
ar: создание libworld.a
ранлиб libworld.a
gcc -o привет hello.o libworld.a

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

% п.м. мир.c
% cons -R / usr / src_only / репозиторий привет
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: создание libworld.a
ранлиб libworld.a
gcc -o привет hello.o libworld.a

вместилище получены файлов

Если дерево репозитория содержит производные файлы (обычно объектные файлы, библиотеки или
исполняемые файлы), Cons выполнит свой обычный расчет подписи, чтобы решить,
файл репозитория обновлен или производный файл должен быть создан локально. Это означает, что,
для обеспечения правильного расчета подписи дерево репозитория также должно содержать
.отправить файлы, которые были созданы Cons при создании производных файлов.

Обычно это достигается путем сборки программного обеспечения в репозитории (или,
в качестве альтернативы в каталоге сборки, а затем копируя результат в репозиторий):

% cd / usr / all / репозиторий
% cons привет
gcc -c привет.с -о привет.о
gcc -c мир.с -о мир.о
ar r libworld.a world.o
ar: создание libworld.a
ранлиб libworld.a
gcc -o привет hello.o libworld.a

(Это безопасно, даже если Строить файл перечисляет / usr / все / репозиторий каталог в
Команда `Repository ', потому что Cons удалит текущий каталог из репозитория
список.)

Теперь, если мы хотим создать копию приложения с нашим собственным Привет файл, нам нужен только
чтобы создать один необходимый исходный файл, и используйте параметр -R, чтобы Cons использовали другой
файлы из репозитория:

% mkdir $ HOME / build1
% cd $ HOME / build1
% ред привет.с
[РЕДАКТИРОВАТЬ]
% cons -R / usr / all / репозиторий привет
gcc -c привет.с -о привет.о
gcc -o привет hello.o /usr/all/repository/libworld.a

Обратите внимание, что Cons не удосужился воссоздать местный libworld.a библиотеку (или перекомпилируйте
мир.о module), но вместо этого использует уже скомпилированную версию из репозитория.

Поскольку подписи MD5, которые Cons помещает в .отправить файл содержит отметки времени для
производные файлы, отметки времени подписи должны соответствовать отметкам времени файла для подписи, чтобы
считаться действительным.

Некоторые программные системы могут изменять метки времени в файлах репозитория (копируя их,
eg), и в этом случае Cons по умолчанию будет предполагать, что подписи репозитория недействительны.
и восстанавливать файлы без надобности. Это поведение можно изменить, указав:

Репозиторий_Sig_Times_OK 0;

Это говорит Cons игнорировать временные метки при принятии решения о том, действительна ли подпись. (Примечание
что избегание этой проверки на работоспособность означает, что над репозиторием должен быть надлежащий контроль
дерево, чтобы гарантировать, что производные файлы не могут быть изменены без обновления .отправить
подпись.)

месте копии of файлов

Если дерево репозитория содержит полные результаты сборки, и мы пытаемся построить из
репозиторий без файлов в нашем локальном дереве, что-то в меру удивительное
бывает:

% mkdir $ HOME / build2
% cd $ HOME / build2
% cons -R / usr / all / репозиторий привет
минусы: "привет" актуально.

Почему "Минусы" говорят, что Здравствуйте программа актуальна, когда нет Здравствуйте программы в
локальный каталог сборки? Поскольку репозиторий (а не локальный каталог) содержит
новейший Здравствуйте программа, а Cons правильно определяет, что ничего делать не нужно, чтобы
восстановите эту последнюю копию файла.

Однако во многих случаях уместно убедиться, что локальная копия
файл всегда существует. Например, сценарий упаковки или тестирования может предполагать, что определенные
сгенерированные файлы существуют локально. Вместо того, чтобы сообщать этим вспомогательным скриптам о
каталог репозитория, команда `Local 'может быть добавлена ​​в Строить or призывник файл в
укажите, что определенный файл или файлы должны появиться в локальном каталоге сборки:

Локальный qw (
Здравствуйте
);

Затем, если мы повторно запустим ту же команду, Cons создаст локальную копию программы из
копия репозитория (сообщающая вам, что это так):

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

Обратите внимание: поскольку создание локальной копии не считается «построением»
Здравствуйте файл, Cons по-прежнему сообщает, что он обновлен.

Создание локальных копий наиболее полезно для файлов, которые устанавливаются в
промежуточный каталог (для совместного использования с другими каталогами) с помощью команды `Install '.
Сопровождение команды `Install 'для файла сопутствующей командой` Local' так
Обычно Cons предоставляет команду Install_Local как удобный способ сделать и то, и другое:

Install_Local $ env, '#export', 'привет';

в точности эквивалентен:

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

Обе команды `Local 'и` Install_Local' обновляют локальный .отправить файл с
соответствующие подписи файлов, чтобы будущие сборки выполнялись правильно.

вместилище зависимость анализ

Благодаря встроенному сканированию Cons будет искать в указанных деревьях репозиториев включенные
.h файлы. Однако, если компилятор также не знает о деревьях репозитория, он будет
невозможно найти .h файлы, которые существуют только в репозитории. Если, например, Привет
файл включает привет.h файл в текущем каталоге:

% cons -R / usr / all / репозиторий привет
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 это дает, когда мы повторно выполняем
команда:

% cons -R / usr / all / репозиторий привет
gcc -c -I. -I / usr / all / репозиторий /usr/all/repository/hello.c -o hello.o
gcc -o привет hello.o /usr/all/repository/libworld.a

Порядок флагов `-I 'повторяет для препроцессора C тот же репозиторий-
путь поиска в каталоге, который Cons использует для собственного анализа зависимостей. Если есть
несколько репозиториев и несколько каталогов CPPPATH, Cons добавит репозиторий
каталоги в начало каждого каталога `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 hello.c -o привет.о

Поскольку Cons полагается на флаги компилятора `-I 'для передачи порядка, в котором
каталоги репозитория должны быть найдены, обработка каталогов репозитория Минусы
принципиально несовместимо с использованием двойных кавычек в директивах `#include 'в вашем C
исходный код:

#include "file.h" / * НЕ ИСПОЛЬЗУЙТЕ ДВОЙНЫЕ ЦИТАТЫ, КАК ЭТО * /

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

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

#включают / * ИСПОЛЬЗУЙТЕ УГЛОВЫЕ КРОНШТЕЙНЫ ВМЕСТО * /

Список репозиториев

Cons предоставляет команду Repository_List для возврата списка всех каталогов репозитория.
в их текущем порядке поиска. Это можно использовать для отладки или для более сложного Perl.
материал:

@list = Список_репозиториев;
печать join ('', @list), "\ n";

вместилище взаимодействие другие Минусы функции

Обработка деревьев репозитория "Минусы" правильно взаимодействует с другими функциями "Минусы", а именно:
Чтобы сказать, он обычно делает то, что вы ожидаете.

В частности, деревья репозиториев правильно и довольно мощно взаимодействуют с 'Link'.
команда. Дерево репозитория может содержать один или несколько подкаталогов для сборок версий.
устанавливается через `Link 'в подкаталог с исходным кодом. Cons будет искать производные файлы в
соответствующие подкаталоги сборки в дереве репозитория.

По умолчанию направлена против

До сих пор мы демонстрировали вызов Cons с явной целью для сборки:

% cons привет

Обычно Cons ничего не строит, если не указана цель, но с указанием '.'
(текущий каталог) все построит:

% cons # ничего не строит

% минусов. # строит все в каталоге верхнего уровня

Добавление метода Default к любому Строить or призывник файл добавит указанный
target в список целей по умолчанию. Минусы построят эти значения по умолчанию, если нет
цели, указанные в командной строке. Итак, добавив следующую строку в верхний уровень
Строить файл будет имитировать типичное поведение Make по умолчанию:

Дефолт '.';

Следующее добавило бы Здравствуйте и Прощай команды (в том же каталоге, что и
Строить or призывник файл) в список по умолчанию:

По умолчанию qw (
Здравствуйте
Прощай
);

Метод Default можно использовать более одного раза для добавления целей в список по умолчанию.

Выборочный запуск строит

Cons предоставляет два метода уменьшения размера данной сборки. Во-первых, указав
target в командной строке, а второй - это метод обрезки дерева сборки. Что ж
сначала рассмотрите целевую спецификацию.

Выборочный запуск направлены

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

% минусов build / hello / hello.o

означает построить привет.о и все, что привет.о может понадобиться. Это из предыдущего
версия Здравствуйте, Мир! программа, в которой привет.о зависел от
экспорт / включить / world.h. Если этот файл устарел (потому что кто-то изменил
src / world / world.h), то он будет перестроен, даже если он находится в каталоге, удаленном от
сборка / привет.

В этом примере:

% минусов сборка

Все в строить каталог создается при необходимости. Опять же, это может привести к увеличению количества файлов
быть построенным. В частности, оба экспорт / включить / world.h и экспорт / lib / libworld.a Он
требуется сборка / привет каталог, и поэтому они будут построены, если они устарели.

Если мы это сделаем, вместо этого:

% минусов на экспорт

то будут перестроены только те файлы, которые должны быть установлены в каталог экспорта, если
необходимо, а затем установил там. Обратите внимание, что cons build может создавать файлы, которые cons
экспорт 'не строит, и наоборот.

Нет `` особенный '' направлена против

При использовании Cons не требуются `` особые '' мишени в стиле make. Самый простой аналог с минусами
использовать специальные экспорт каталоги вместо этого. Предположим, например, что у вас есть
целая серия модульных тестов, связанных с вашим кодом. Тесты живут в
исходный каталог рядом с кодом. Однако обычно вы не хотите создавать эти тесты.
Одно из решений - предоставить все инструкции по сборке для создания тестов, а затем
установить тесты в отдельную часть дерева. Если мы установим тесты на верхнем уровне
каталог называется тестов, затем:

% минусов тесты

построю все тесты.

% минусов на экспорт

создаст производственную версию системы (но не тесты) и:

% минусов сборка

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

Если вы хотите создать только один тест, вы можете явно назвать тест (в
либо тестов каталог или строить каталог). Вы также можете агрегировать тесты
в удобную иерархию в каталоге тестов. Эта иерархия не требует
обязательно соответствовать исходной иерархии во многом таким же образом, как иерархия включения
вероятно, не соответствует исходной иерархии (иерархия включения вряд ли будет больше
глубиной более двух уровней для программ на языке C).

Если вы хотите построить абсолютно все в дереве (в зависимости от того, какие варианты вы
select), вы можете использовать:

% минусов.

Это не особенно эффективно, так как будет обходиться по всем деревьям без необходимости,
включая дерево исходных текстов. В исходном дереве, конечно, могут быть построенные объекты в
это - ничто не мешает вам это делать, даже если вы обычно строите отдельную сборку
дерево.

строить Обрезка

В сочетании с выбором цели строить обрезка может использоваться для уменьшения объема
строить. В предыдущем примере peAcH и baNaNa мы уже видели, как
обрезку сборки можно использовать, чтобы сделать доступной только половину потенциальной сборки для любого заданного
вызов "cons". Cons также предоставляет для удобства соглашение командной строки, которое
позволяет указать, какие призывник файлы фактически `` собираются '', то есть включаются
в дерево сборки. Например:

% минусов сборка + мир

Аргумент `+ 'вводит регулярное выражение Perl. Это, конечно, должно быть процитировано на
уровень оболочки, если в выражении есть метасимволы оболочки. В
выражение сопоставляется с каждым призывник файл, который был упомянут в `Build '
оператор, и только те скрипты с совпадающими именами фактически включаются в
построить дерево. Допускается несколько таких аргументов, и в этом случае сопоставление с любым из них.
достаточно для включения скрипта.

В приведенном выше примере Здравствуйте программа не будет построена, т.к. минусов не будет
знание сценария привет / призывник, libworld.a архив будет построен, однако, если
нужно быть.

Есть несколько вариантов использования сокращения сборки через командную строку. Пожалуй, самый полезный
способность вносить локальные изменения, а затем при достаточном знании
последствия этих изменений, ограничьте размер дерева сборки, чтобы ускорить
время восстановления. Второе использование сокращения сборки - активное предотвращение перекомпиляции.
определенных файлов, которые, как вы знаете, будут перекомпилированы, например, из-за измененного файла заголовка.
Возможно, вы знаете, что либо изменения в файле заголовка несущественны, либо
изменения могут быть проигнорированы для большей части дерева в целях тестирования.
точка зрения состоит в том, что допустить такой тип поведения прагматично, с пониманием того, что
при следующей полной сборке все, что нужно будет перестроить, будет. Нет эквивалента
на команду `` сделать касание '', чтобы пометить файлы как постоянно обновленные. Так что любой риск
понесенные обрезкой сборки смягчаются. Для качественной работы релиза, очевидно, мы рекомендуем
что вы не используете обрезку сборки (однако ее можно использовать во время интеграции,
для проверки компиляции и т. д. Просто убедитесь, что вы сделали неограниченную сборку перед фиксацией
интеграция).

Временная переопределения

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

% cons -o сверх экспорта

построит экспорт каталог со всеми производными файлами, на которые распространяются переопределения.
в за файл. Если вы опустите опцию `-o ', тогда все необходимое для удаления
все переопределения будут восстановлены.

Переопределение охрана окружающей среды переменные

Файл переопределения может содержать два типа переопределений. Первый - это входящая среда
переменные. Обычно они доступны Строить файл из хэша `% ENV '
Переменная. Их можно тривиально переопределить в файле переопределения, установив параметр
соответствующие элементы `% ENV '(они также могут быть переопределены в среде пользователя,
конечно).

Ассоциация Override команду

Второй тип переопределения выполняется с помощью команды `Override ', которая выглядит так:
это:

Переопределить , => , => , ...;

Регулярное выражение RegExp сопоставляется с каждым производным файлом, который является кандидатом
для сборки. Если производный файл совпадает, то пары переменная / значение используются для
переопределить значения в среде конструирования, связанные с производным файлом.

Предположим, у нас есть такая среда построения:

$ МИНУСЫ = новые минусы (
COPT => ',
CDBG => '-g',
CFLAGS => '% COPT% CDBG',
);

Тогда, если у нас есть файл переопределения за содержащий эту команду:

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

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

Вот оригинальная версия Hello, World! программа, построенная в этой среде.
Обратите внимание, что Cons перестраивает соответствующие части при применении или удалении переопределения:

% cons привет
cc -g -c привет.с -о привет.о
cc -o привет привет.о
% cons -o за привет
cc -O -c привет.с -о привет.о
cc -o привет привет.о
% cons -o за привет
минусы: "привет" актуально.
% cons привет
cc -g -c привет.с -о привет.о
cc -o привет привет.о

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

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

Больше on строительство средах

По умолчанию строительство переменные

Мы упомянули и использовали концепцию строительство охрана окружающей среды, много раз в
предыдущие страницы. Теперь пора сделать это более конкретным. Со следующими
заявление:

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

создается ссылка на новую среду конструирования по умолчанию. Это содержит номер
конструктивных переменных и некоторых методов. На данный момент список по умолчанию
Переменные конструкции определяются следующим образом:

CC => 'cc',
CFLAGS => '',
CCCOM => '% CC% CFLAGS% _IFLAGS -c% <-o%>',
INCDIRPREFIX => '-I',
CXX => '% CC',
CXXFLAGS => '% CFLAGS',
CXXCOM => '% CXX% CXXFLAGS% _IFLAGS -c% <-o%>',
ССЫЛКА => '% CXX',
LINKCOM => '% LINK% LDFLAGS -o%>% <% _LDIRS% LIBS',
LINKMODULECOM => '% LD -r -o%>% <',
LIBDIRPREFIX => '-L',
AR => 'ar',
ARFLAGS => 'r',
ARCOM => "% AR% ARFLAGS%>% <\ n% RANLIB%>",
RANLIB => 'ранлиб',
AS => 'как',
ASFLAGS => '',
ASCOM => '% AS% ASFLAGS% <-o%>',
LD => 'ld',
LDFLAGS => '',
PREFLIB => 'библиотека',
СУФЛИБ => '.a',
SUFLIBS => '.so: .a',
SUFOBJ => '.o',
ENV => {'ПУТЬ' => '/ бен:/ USR / бен'},

В системах 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:%>% <",
РАНЛИБ => '',
LD => 'ссылка',
LDFLAGS => '/ nologo',
PREFLIB => '',
SUFEXE => '.exe',
СУФЛИБ => '.lib',
SUFLIBS => '.dll: .lib',
SUFOBJ => '.obj',

Эти переменные используются различными методами, связанными с окружением, в
в частности, любой метод, который в конечном итоге вызывает внешнюю команду, заменит эти
переменные в финальную команду, если это необходимо. Например, метод Objects принимает
ряд исходных файлов и механизмы для получения, при необходимости, соответствующего объекта
файлы. Например:

Объекты $ env 'foo.c', 'bar.c';

Это позволит при необходимости произвести фу.о и бар.о. Вызываемая команда просто
% CCCOM, который расширяется путем подстановки до соответствующей требуемой внешней команды
построить каждый объект. Мы рассмотрим правила замены далее под заголовком "Command".
метод, ниже.

Переменные конструкции также используются для других целей. Например, "CPPPATH" - это
используется для указания пути к подключаемым каталогам через двоеточия. Они предназначены для
передаются препроцессору C, а также используются механизмом сканирования файлов C для
определить зависимости, задействованные в компиляции C. Переменные, начинающиеся с
подчеркивание, создаются различными способами и обычно считаются `` внутренними ''
переменные. Например, когда вызывается метод, который вызывает создание объекта
из источника C создается переменная `_IFLAGS ': это соответствует переключателям` -I'
требуется компилятором C для представления каталогов, указанных параметром CPPPATH.

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

Переменные CFLAGS, LDFLAGS и ARFLAGS предоставляют место для передачи параметров в
компилятор, загрузчик и архиватор соответственно. Менее очевидно, что `INCDIRPREFIX '
переменная определяет строку параметров, которая будет добавлена ​​к началу каждого включаемого
каталог, чтобы компилятор знал, где найти .h файлы. Точно так же
Переменная LIBDIRPREFIX определяет строку параметра, добавляемую в начало
каждый каталог, в котором компоновщик должен искать библиотеки.

Другая переменная, ENV, используется для определения системного окружения во время выполнения.
внешней команды. По умолчанию единственная установленная переменная среды - PATH,
который является путем выполнения команды UNIX. Для максимальной воспроизводимости следует
действительно организовать, чтобы установить свой собственный путь выполнения на вашем верхнем уровне Строить файл (или
возможно, импортировав соответствующий строительный пакет с помощью команды Perl `use '). В
переменные по умолчанию предназначены для того, чтобы помочь вам начать работу.

Интерполяция строительство переменные

Переменные среды конструирования могут быть интерполированы в имена исходного и целевого файлов.
добавив к имени конструкционной переменной префикса `% '.

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

Расширение переменных конструкции является рекурсивным - то есть файл имя(s) будет повторно
расширяется до тех пор, пока больше нельзя будет делать замены. Если конструкционная переменная не
определено в среде, то вместо нее будет подставлена ​​пустая строка.

По умолчанию строительство методы

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

Ассоциация "новый" конструктор

Новый метод - это конструктор объекта Perl. То есть он не вызывается через ссылку
к существующей строительной среде ссылка, но, скорее, статически, используя имя
Perl пакет где определен конструктор. Метод вызывается так:

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

Окружение, которое вы возвращаете, благословлено пакетом `cons ', что означает, что он будет
связали с ним методы по умолчанию, описанные ниже. Индивидуальное строительство
переменные можно переопределить, указав пары имя / значение в списке переопределения. Обратите внимание, что
чтобы переопределить любую переменную окружения команды (то есть что-либо в `ENV '), вам нужно будет
перекрыть их все. Вы можете обойти эту трудность, используя метод "копирования" на
существующая строительная среда.

Ассоциация `клон ' метод

Метод clone создает клон существующей среды конструирования и может быть
называется, как в следующем примере:

$ env2 = $ env1-> clone ( );

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

Ассоциация `копировать ' метод

Метод `copy 'извлекает определяемые извне конструкционные переменные из
environment и возвращает их как список пар имя / значение. Переопределения также могут быть
при условии, что в этом случае будут возвращены переопределенные значения. В
возвращенный список может быть назначен хешу, как показано в прототипе ниже, но он также может
можно манипулировать другими способами:

% env = $ env1-> копия ( );

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

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

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

Ассоциация `Установить ' метод

Метод `Install 'обеспечивает установку указанных файлов в указанном
каталог. Оптимизирована установка: файл не копируется, если его можно связать. Если
это нежелательное поведение, вам нужно будет использовать другой метод для установки
файл. Он называется следующим образом:

Установить $ env , ;

Обратите внимание, что, хотя имена устанавливаемых файлов могут быть произвольными, только последние
компонент каждого имени используется для установленного целевого имени. Так, например, если вы
организовать установку foo / bar in Баз, это создаст бар подать в Баз каталог (не
foo / bar).

Ассоциация `InstallAs ' метод

Метод InstallAs упорядочивает указанный источник файл(ы) для установки в качестве
указанная цель файл(s). В виде списка файлов следует указать несколько файлов. В
оптимизирована установка: файл не копируется, если его можно связать. Если это не
желаемого поведения, вам нужно будет использовать другой метод для установки файла. это
называется следующим образом:

InstallAs работает двумя способами:

Установка одним файлом:

InstallAs $ env TgtFile, SrcFile;

Установка нескольких файлов:

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

Или даже как:

@srcs = qw (src1 src2 src3);
@tgts = qw (tgt1 tgt2 tgt3);
Установить как $ env [@tgts], [@srcs];

И целевой, и исходный списки должны быть одинаковой длины.

Ассоциация "Драгоценный" метод

Метод `Precious 'просит cons не удалять указанный файл или список файлов раньше.
строить их снова. Он вызывается как:

Драгоценный ;

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

Ассоциация "Команда" метод

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

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

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

В команде построения любая переменная из среды построения может быть
вводится добавлением к имени конструкционной переменной префикса `% '. Это рекурсивно:
команда расширяется до тех пор, пока больше нельзя будет сделать замены. Если конструкция
переменная не определена в среде, тогда будет подставлена ​​пустая строка. А
удвоенный `%% 'будет заменен одиночным`%' в команде построения.

Есть несколько псевдопеременных, которые также будут расширены:

%> Имя целевого файла (в многоцелевой команде это всегда первая цель
упомянул).

% 0 То же, что и `%> '.

% 1,% 2, ...,% 9
Они относятся к входному файлу с первого по девятый соответственно.

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

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

If TGT необходимо обновить, тогда это приведет к выполнению
следующие команды, предполагая, что не было установлено переназначение для тестXNUMX
каталог:

эхо-тест / бар-тест / baz -i test / foo> test / tgt
эхо-тест / foo test / baz -i test / bar >> test / tgt
эхо-тест / foo test / bar -i test / baz >> test / tgt

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

: a абсолютный путь к имени файла
: b каталог плюс имя файла без суффикса
: d каталог
: f имя файла
: s суффикс имени файла
: F имя файла без суффикса

Продолжая приведенный выше пример, `% <: f 'будет расширяться до` foo bar baz', а `% ': d>
развернуть до `test '.

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

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

Это выполнит:

echo '# Ключевые слова: foo, bar, baz'> tgt
кошка tgt.in >> tgt

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

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

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

Предполагается, что первое слово каждой командной строки после раскрытия является исполняемым файлом.
искала переменную окружения PATH (которая, в свою очередь, указана
Конструктивная переменная ENV). Если эта команда найдена на пути, то цель будет
зависеть от него: поэтому команда будет автоматически построена по мере необходимости. Это
в некоторые оболочки можно писать команды, состоящие из нескольких частей, через точку с запятой. Только
от первого командного слова будет зависеть, поэтому, если вы напишете свои командные строки
таким образом, вы должны либо явно установить зависимость (с помощью метода `Depends '), либо
убедитесь, что используемая вами команда является системной командой, которая, как ожидается, будет
доступный. Если он недоступен, вы, конечно, получите сообщение об ошибке.

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

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

Обратите внимание, что при выполнении команды вы находитесь в том же пакете, что и при выполнении команды. Строить
or призывник файл был прочитан, поэтому вы можете вызывать функции Perl, которые вы определили в том же
Строить or призывник файл, в котором появляется `Команда ':

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

Строка Perl будет использоваться для генерации подписи для производного файла, поэтому, если вы
измените строку, файл будет перестроен. Содержимое всех вызываемых вами подпрограмм,
однако, не являются частью подписи, поэтому, если вы измените вызываемую подпрограмму, например
create_file выше, цель будет не быть восстановленным. Будьте внимательны.

Cons обычно выводит команду перед ее выполнением. Это поведение подавляется, если
первый символ команды - `@ '. Обратите внимание, что вам может потребоваться отделить `@ 'от
имя команды или экранировать его, чтобы @cmd не выглядел как массив в кавычках Perl
операторы, выполняющие интерполяцию:

# Первая командная строка неверна,
# потому что "@cp" выглядит как массив
# в функцию Perl qq //.
# Вместо этого используйте вторую форму.
Команда $ env 'foo', 'foo.in', qq (
@cp% <временный файл
@ cp tempfile%>
);

Если где-нибудь в развернутой командной строке есть метасимволы оболочки, такие как `<',
`> ', кавычки или точка с запятой, тогда команда будет фактически выполнена путем вызова
оболочка. Это означает, что такая команда, как:

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

сам по себе обычно не работает, поскольку на пути нет команды cd. Но команда
строка:

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

при расширении будет по-прежнему содержать точку с запятой метасимвола оболочки, а оболочка будет
вызывается для интерпретации команды. Поскольку `cd 'интерпретируется этой суб-оболочкой, команда
будет выполняться, как ожидалось.

Чтобы указать команду с несколькими целями, вы можете указать ссылку на список
цели. В Perl ссылку на список можно создать, заключив список в квадратные скобки.
Отсюда следующая команда:

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

может использоваться в случае, когда команда `gen 'создает два файла, оба фу.ч и foo.c.

Ассоциация `Объекты ' метод

Метод `Objects 'организует создание объектных файлов, соответствующих указанным
исходные файлы. Он вызывается, как показано ниже:

@files = Объекты $ env ;

В Unix исходные файлы, заканчивающиеся на .s и .c в настоящее время поддерживаются и будут скомпилированы
в имя того же файла, заканчивающееся на .o. По умолчанию все файлы создаются путем вызова
внешняя команда, которая является результатом расширения переменной конструкции CCCOM, с
`% <'и`%>' устанавливаются для исходного и объектного файлов соответственно (см. метод `Command '
для подробностей о расширении). Переменная CPPPATH также используется при сканировании исходных файлов.
для зависимостей. Это список имен путей, разделенных двоеточиями, который также используется для создания
переменная конструкции `_IFLAGS ', которая будет содержать соответствующий список -`I'
варианты для компиляции. Любые относительные пути в CPPPATH интерпретируются как относительные.
в каталог, в котором была создана соответствующая среда конструирования (абсолютный
и имена верхних родственников также могут использоваться). Эта переменная используется CCCOM. Поведение
этой команды можно изменить, изменив любую из переменных, которые интерполируются
в CCCOM, например CC, CFLAGS и косвенно CPPPATH. Также возможно
заменить само значение `CCCOM '. Для удобства этот файл возвращает список
имена файлов объектов.

Ассоциация "Программа" метод

Метод `Program 'организует связь указанной программы с указанным объектом.
файлы. Он вызывается следующим образом:

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

К имени программы будет добавлено значение конструктивной переменной SUFEXE (
по умолчанию, `.exe 'в системах Win32, ничего в системах Unix), если суффикс еще не установлен
настоящее время.

Исходные файлы могут быть указаны вместо файлов объектов - метод `Объекты 'будет
вызывается для преобразования всех файлов в объектные файлы и, следовательно, все
Замечания о методе `Objects ', приведенные выше, применимы и к этому методу.

Фактическое связывание программы будет производиться внешней командой, результатом которой будет
от расширения переменной конструкции `LINKCOM 'с`% <', установленным для объектных файлов в
быть связанными (в представленном порядке), а `%> 'установить на цель (см. метод` Command'
для подробностей о расширении). Пользователь может установить дополнительные переменные в конструкции
окружение, включая `LINK ', чтобы определить, какую программу использовать для связывания,` LIBPATH',
список путей поиска библиотек, разделенных двоеточиями, для использования со спецификациями библиотек
форма -llib, и `LIBS ', определяя список библиотек для компоновки (в любом -llib
форме или просто как пути. Относительные пути в LIBPATH и LIBS интерпретируются.
относительно каталога, в котором создается соответствующая среда конструирования
(также могут использоваться абсолютные и относительные имена). Минусы автоматически настраиваются
зависимости от любых библиотек, упомянутых в `LIBS ': эти библиотеки будут построены раньше
команда связана.

Ассоциация `Библиотека ' метод

Метод `Library 'организует создание указанной библиотеки из указанного объекта.
файлы. Он вызывается следующим образом:

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

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

Исходные файлы могут быть указаны вместо файлов объектов - метод `Объекты 'будет
вызывается для преобразования всех файлов в объектные файлы и, следовательно, все
Замечания о методе `Objects ', приведенные выше, применимы и к этому методу.

Фактическое создание библиотеки будет производиться внешней командой, результатом которой будет
от раскрытия конструктивной переменной ARCOM, с установкой% <на элементы библиотеки (в
в представленном порядке) и `%> 'к создаваемой библиотеке (см. метод` Command' для
детали расширения). Пользователь может установить переменные в среде построения, которые будут
влияют на работу команды. К ним относятся `AR ', программа для архивирования, которую нужно использовать,
ARFLAGS, который может использоваться для изменения флагов, заданных программе, указанной параметром AR,
и `RANLIB ', имя программы генерации индекса архива, если необходимо (если конкретный
не требует последней функциональности, тогда `ARCOM 'необходимо переопределить, чтобы не
ссылка "РАНЛИБ").

Метод `Library 'позволяет указать одну и ту же библиотеку в нескольких методах.
призывы. Все участвующие объекты из всех вызовов (которые могут быть из
разные каталоги) объединяются и генерируются одной командой архивирования. Примечание,
однако, если вы сократите сборку так, чтобы была указана только часть библиотеки, тогда только
эта часть библиотеки будет сгенерирована (остальное исчезнет!).

Ассоциация `Модуль ' метод

Метод Module представляет собой комбинацию методов Program и Command. Скорее, чем
непосредственно генерируя исполняемую программу, эта команда позволяет вам указать свой собственный
команда для фактического создания модуля. Метод вызывается следующим образом:

Модуль $ env , , ;

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

Ассоциация `Зависит ' метод

Метод `Depends 'позволяет вам указать дополнительные зависимости для цели. это
вызывается следующим образом:

Зависит от $ env , ;

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

Набор идентичных зависимостей для нескольких целей может быть указан с помощью ссылки на
список целей. В Perl ссылку на список можно создать, заключив список в квадрат.
скобки. Отсюда следующая команда:

Зависит от $ env ['foo', 'bar'], 'input_file_1', 'input_file_2';

указывает, что оба Foo и бар файлы зависят от перечисленных входных файлов.

Ассоциация "Игнорировать" метод

Метод `Ignore 'позволяет вам явно игнорировать зависимости, которые Cons выводит на свои
своя. Он вызывается следующим образом:

Игнорировать ;

Это можно использовать, чтобы избежать повторной компиляции из-за изменений в файлах системных заголовков или
утилиты, о которых известно, что они не влияют на сгенерированные цели.

Если, например, программа построена в каталоге, смонтированном по NFS в нескольких системах, которые
иметь разные копии стдио.ч, различия повлияют на подписи всех
производные цели, построенные из исходных файлов, которые `#include '. Это вызовет все
эти цели должны быть восстановлены при изменении систем. Если это нежелательное поведение,
то следующая строка удалит зависимости от стдио.ч файл:

Игнорировать '^ / usr / include / stdio \ .h $';

Обратите внимание, что аргументами метода `Ignore 'являются регулярные выражения, поэтому особые
символы должны быть экранированы, и вы можете захотеть привязать начало или конец
выражение с символами `^ 'или` $'.

Ассоциация `Соль ' метод

Метод `Salt 'добавляет постоянное значение к вычислению сигнатуры для каждого производного
файл. Он вызывается следующим образом:

Соль $ строка;

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

Соль `uname -s`;

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

Ассоциация `UseCache ' метод

Метод UseCache инструктирует Cons поддерживать кэш производных файлов для совместного использования.
между отдельными деревьями сборки одного и того же проекта.

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

Ассоциация SourcePath метод

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

$ path = SourcePath ;

Ассоциация ConsPath метод

Метод ConsPath возвращает истину, если предоставленный путь является производным файлом, и возвращает
undef (ложь) в противном случае. Он вызывается следующим образом:

$ 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
-час'. Это может быть использовано для предоставления документации по конкретным целям, значениям, построению
параметры и т. д. для дерева построения. Он вызывается следующим образом:

Помощь ;

Метод `Help 'может быть вызван только один раз и обычно должен указываться в верхней части страницы.
уровень Строить .

простирающийся Минусы

Переопределение строительство переменные

Есть несколько способов расширить минусы, которые различаются по степени сложности. Простейший
Метод состоит в том, чтобы определить вашу собственную среду строительства на основе среды по умолчанию,
но изменен, чтобы отразить ваши конкретные потребности. Этого часто бывает достаточно для C-based
Приложения. Вы можете использовать конструктор new, а также методы clone и copy для
создавать гибридные среды. Эти изменения могут быть полностью прозрачными для лежащих в основе
призывник файлы.

Добавление new методы

Для чуть более требовательных изменений вы можете добавить новые методы в раздел «cons».
упаковка. Вот пример очень простого расширения InstallScript, которое устанавливает
tcl в запрошенном месте, но сначала редактирует сценарий, чтобы отразить платформу.
зависимый путь, который необходимо установить в скрипте:

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

sub cons :: InstallScript {
мой ($ env, $ dst, $ src) = @_;
Команда $ env $ dst, $ src, qq (
sed s + ваш-путь-здесь + $ BIN_DIR +% <>%>
chmod oug + x%>
);
}

Обратите внимание, что этот метод определен непосредственно в пакете cons (с помощью префикса имени
с `cons :: '). Внесенное таким образом изменение будет глобально видимым для всех сред,
и может вызываться, как в следующем примере:

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

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

Переопределение методы

Вместо добавления метода в пространство имен cons, вы можете определить новый пакет
который наследует существующие методы из пакета cons и переопределяет или добавляет другие. Этот
может быть выполнено с использованием механизмов наследования Perl.

В следующем примере определяется новый пакет cons :: switch, который отменяет стандартный
"Библиотечный" метод. Переопределенный метод создает модули связанных библиотек, а не библиотеки.
архивы. Предоставляется новый конструктор. Среды, созданные с помощью этого конструктора, будут
есть новый библиотечный метод; другие не будут.

минусы пакета :: переключатель;
НАЧАТЬ {@ISA = 'cons'}

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

вспомогательная библиотека {
мой ($ env) = сдвиг;
мой ($ lib) = сдвиг;
my (@objs) = Объекты $ env @_;
Команда $ env $ lib, @objs, q (
% LD -r% LDFLAGS% <-o%>
);
}

Эту функцию можно вызвать, как в следующем примере:

$ env = new cons :: switch (@overrides);
...
Библиотека $ env 'lib.o', 'foo.c', 'bar.c';

Вызов Минусы

Команда cons обычно вызывается из корня дерева сборки. А Строить файл
должен существовать в этом каталоге. Если используется аргумент -f, то альтернативный Строить
может быть использован файл (и, возможно, альтернативный корень, так как cons будет cd к Строить
каталог, содержащий файл).

Если cons вызывается из дочернего элемента корня дерева сборки с аргументом -t, он
будет подниматься по иерархии каталогов в поисках Строить файл. (Альтернативное имя может
по-прежнему указывается с помощью `-f '.) Цели, указанные в командной строке, будут изменены
относиться к открытому Строить файл. Например, из каталога, содержащего
на высшем уровне Строить файл, следующий вызов:

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

в точности эквивалентен:

% cons libfoo / подкаталог / цель

Если есть какие-либо цели "По умолчанию", указанные в иерархии каталогов Строить or
призывник файлы, только цели по умолчанию в или ниже каталога, из которого `cons -t '
был вызван, будет построен.

Команда вызывается следующим образом:

минусы -

в котором Аргументы может быть любым из следующих в любом порядке:

цель Постройте указанную цель. Если цель это каталог, затем рекурсивно построить
все в этом каталоге.

+ узор Ограничить призывник файлы считаются только теми, которые соответствуют описания, Которая является
регулярное выражение Perl. Допускается несколько аргументов "+".

имязнак равно
Наборы имя оценивать волна в хэше ARG передается на верхний уровень Строить .

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

`-cd 'Отключить кеширование. Не извлекать из кеша и не сбрасывать в кеш.

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

`-cs 'Синхронизировать существующие целевые объекты сборки, которые оказались актуальными с кешем.
Это полезно, если кеширование было отключено с помощью -cc или было включено совсем недавно.
с UseCache.

`-d 'Включить отладку зависимостей.

`-f '
Использовать указанный файл вместо Строить (но сначала измените содержание
каталог файл).

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

`-k 'Продолжайте идти как можно дальше после ошибок.

`-o '
Прочитать файл переопределения файл.

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

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

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

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

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

`-R '
Искать файлы в РЕПО, множественный -R РЕПО каталоги ищутся в
заказ указан.

`-t 'Перемещаться вверх по иерархии каталогов в поисках Строить файл, если его нет
в текущем каталоге. Цели будут изменены, чтобы соответствовать
Строить .

`-v 'Показать версию` cons' и продолжить обработку.

`-V 'Показать версию` cons' и выйти.

`-wf '
Запишите все рассматриваемые имена файлов в файл.

`-x 'Показать справочное сообщение, подобное этому, и выйти.

И, аргументы конструкции могут быть любыми аргументами, которые вы хотите обработать в Строить .
Обратите внимание, что должен быть -- разделяя аргументы на против и аргументы, которые вы
желаю обрабатывать в Строить .

Обработка аргументы конструкции можно сделать любым стандартным пакетом, например Геопт или его
варианты или любой пользовательский пакет. минусы пройдет в аргументы конструкции as @АРГВ и
не будет пытаться что-либо интерпретировать после --.

% cons -R / usr / local / repository -d os = solaris + driver - -c test -f DEBUG

передал бы следующее к минусам

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

и далее на верхний уровень Строить подать как @АРГВ

-c test -f ОТЛАДКА

Обратите внимание, что cons -r. эквивалентен полному рекурсивному `make clean ', но не требует
поддержка в Строить файл или любой призывник файлы. Это наиболее полезно, если вы
компиляция файлов в исходные каталоги (если вы разделите строить и экспорт каталоги,
тогда можно просто удалить каталоги).

Опции `-p ',` -pa' и `-pw 'чрезвычайно полезны для использования в качестве помощи при чтении
скрипты или их отладка. Если вы хотите знать, какой скрипт устанавливает экспорт / включить / foo.h,
например, просто введите:

% cons -pw export / include / foo.h

. и письмо зависимость Сканеры

QuickScan позволяет настроить простые независимые от цели сканеры для исходных файлов. Только
один сканер QuickScan может быть связан с любым исходным файлом и средой.

QuickScan вызывается следующим образом:

QuickScan CONSENV CODEREF, ИМЯ ФАЙЛА [, ПУТЬ]

Ожидается, что подпрограмма, на которую ссылается CODEREF, вернет список включенных имён файлов.
непосредственно ФАЙЛОМ. Эти имена файлов, в свою очередь, будут сканироваться. Необязательный аргумент PATH
предоставляет путь поиска для поиска FILENAME и / или файлов, возвращаемых предоставленным пользователем
подпрограмма. PATH может быть ссылкой на массив имен справочников или
строка имен, разделенных системным разделителем (':' в системах UNIX, ';' в
Windows NT).

Подпрограмма вызывается один раз для каждой строки в файле, при этом $ _ устанавливается на текущую строку.
Если подпрограмме нужно просмотреть дополнительные строки или, если на то пошло, весь файл,
тогда он может сам их прочитать из файлового дескриптора SCAN. Он также может завершить цикл, если
он знает, что дополнительная информация о включении недоступна, закрывая дескриптор файла.

Независимо от того, указан ли путь поиска, QuickScan сначала пытается найти файл.
относительно текущего каталога (для файла верхнего уровня, поставляемого непосредственно в QuickScan),
или из каталога, содержащего файл, ссылающийся на файл. Это не очень
в общем, но кажется достаточно хорошим - особенно если у вас есть возможность написать свой собственный
утилиты и могут стандартным образом контролировать использование пути поиска. Наконец,
Путь поиска в настоящее время разделяется двоеточием. Это может не сделать лагерь Нового Завета счастливым.

Вот реальный пример, взятый из Строить файл здесь:

вспомогательные минусы :: SMFgen {
мой ($ env, @tables) = @_;
foreach $ t (@tables) {
$ env-> QuickScan (sub {/\b\S*?\.smf\b/g}, "$ t.smf",
$ env -> {SMF_INCLUDE_PATH});
$ env-> Команда (
[«$ 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, фактически вызывается).

Сканер вызывается только для данного исходного файла, если он нужен какой-либо цели в
дерево. Он вызывается только один раз для данного исходного файла.

Вот еще один способ построить такой же сканер. Здесь используется явная ссылка на код,
а также (в данном случае необязательно) читает сам файл:

суб myscan {
мой (@includes);
делать {
push (@includes, /\b\S*?\.smf\b/g);
} пока ;
@включает
}

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

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

ПОДДЕРЖКИ И SUGGESTIONS

Минусы поддерживаются сообществом пользователей. Чтобы подписаться, отправьте письмо по адресу минусы-обсуждение-
[электронная почта защищена] с телом подписаться.

Пожалуйста, сообщайте о любых предложениях через [электронная почта защищена] список рассылки.

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