makepp_repositories - Интернет в облаке

ПРОГРАММА:

ИМЯ

makepp_repositories - Как использовать репозитории для вариантных сборок, для поддержки
центральный набор источников и прочее

ОПИСАНИЕ

A хранилище - это каталог или иерархия каталогов за пределами каталога по умолчанию, который
содержит файлы, которые нужны make-файлу в текущем дереве каталогов. Макэпп может
автоматически связывать файлы из репозитория с текущим деревом каталогов, если они
нужный. Репозитории предоставляют те же функции, что и переменная "VPATH", но (в отличие от
"VPATH" в других версиях make) вам не нужно делать ничего особенного с вашим make-файлом.
чтобы заставить их работать.

Репозитории указываются с помощью параметра командной строки «-R» или «--repository» либо с помощью параметра
оператор "репозиторий" в make-файле. Обратите внимание: если у вас есть привычка вызывать makepp
в разных подкаталогах вашего дерева сборки легко случайно повторно импортировать
репозиторий в другом месте. В качестве защиты от этого, если вы используете RootMakeppfile, макияж
откажется запускаться, если найдет один выше или ниже того места, где он будет импортирован.

Это несколько сравнимо с файловыми системами union в операционной системе (unionfs ...).
текущий каталог похож на слой самого высокого уровня, доступный для записи. Все репозитории похожи на
нижние слои только для чтения.

Репозитории полезны в нескольких различных ситуациях:

· Если вы хотите поместить свой объект и исполняемые файлы в отдельный каталог, но
make-файл написан так, чтобы помещать их в тот же каталог, что и исходные коды.

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

· Когда у вас нет доступа на запись ко всему или части исходного дерева.

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

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

В Makepp есть еще один механизм, называемый строить кэш который решает некоторые из тех же
вроде проблемы как с репозиториями по разному. В зависимости от вашей проблемы сборка
кеш может быть более полезным, чем репозиторий. См. Makepp_build_cache для получения информации о
кеши сборки и сравнение кешей сборки и репозиториев.

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

Другой компиляция кредита

Предположим, у вас есть простая программа с make-файлом, который выглядит примерно так:

CFLAGS = -O2
ОБЪЕКТЫ = ao bo co
моя_программа: $ (ОБЪЕКТЫ)
cc $ (входы) -o $ (выход)

% .o:% .c
cc $ (CFLAGS) -c $ (ввод) -o $ (вывод)

Этот make-файл помещает файлы «ao», «bo», «co» и «my_program» в один и тот же каталог.
как исходные файлы.

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

Однако с репозиторием вам вообще не нужно трогать свой make-файл. Рассмотрим
следующая последовательность команд:

% компакт-диск my_program_source
% makepp # Создает с использованием вышеуказанного make-файла и
# объектные файлы переходят в каталог
# источник_моей_программы.
% CD ..
% mkdir binary-debug # Создайте чистый каталог для сборки
% cd binary-debug # та же программа с разными параметрами.
% makepp -R ../my_program_source CFLAGS = -g
# Теперь объекты переходят в двоичную отладку.

Первая команда makepp компилирует исходные файлы с оптимизацией и помещает объекты
в каталог "my_program_source", потому что это то, что должен делать make-файл.
делать. Теперь мы хотим перестроить программу, но мы хотим изменить значение «CFLAGS» на
скомпилировать для отладки. Мы указываем новое значение «CFLAGS» в командной строке, а также
сообщите makepp, что каталог «my_program_source» является репозиторием, используя параметр «-R».

Каждый раз, когда makepp понимает, что ему нужен файл, которого у него еще нет в текущем
каталог, он смотрит в репозиторий. В этом случае он сначала ищет make-файл,
которого нет в подкаталоге "binary-debug". Таким образом, создается символическая ссылка на
это из make-файла в "my_program_source", а затем считывается в make-файле. Затем это
замечает, что ему нужен файл «ac» для построения «ao», и поэтому он ссылается на «ac»
из репозитория. Если "ac" включает любые файлы, содержащиеся в "my_program_source", тогда
они также будут автоматически связаны. Примечание: эти ссылки полезны для вещей
как отладка, но если они вам не нравятся, "makeppclean -R" может удалить их.

Выполнение команды сборки в "binary-debug" не коснется ни одного из файлов в
"my_program_source". Таким образом, из одного и того же набора исходных файлов у вас теперь есть два разных
копии программы, одна скомпилирована с оптимизацией, а другая - для отладки. А также
это произошло без обращения к make-файлу.

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

Восстановление one файл a небольшая модификация в компиляция команды

Makepp не извлекает из репозитория только исходные файлы. Если объектные файлы в
репозиторий не нужно перестраивать, он будет их использовать. Например, рассмотрим небольшой
модификация вышеуказанного make-файла:

CFLAGS: = -O2
A_CFLAGS: = -O6 -funroll-loops

ОБЪЕКТЫ: = ao bo co

моя_программа: $ (ОБЪЕКТЫ)
cc $ (входы) -o $ (выход)

% .o:% .c
cc $ (CFLAGS) -c $ (ввод) -o $ (вывод)

ао: ас
cc $ (A_CFLAGS) -c $ (ввод) -o $ (вывод)

Идея состоит в том, что "ao" содержит критичный ко времени код, поэтому он компилируется с более высоким
оптимизация, чем остальные объекты. Теперь предположим, что мы хотим проверить, насколько разные
сроки указаны с разными вариантами компиляции. В этом тоже может помочь репозиторий:

% компакт-диск my_program_source
% makepp # Создает с использованием вышеуказанного make-файла и
# объектные файлы переходят в каталог
# источник_моей_программы.
% CD ..
% mkdir no-unrolling # Создайте чистый каталог для сборки
% cd no-unrolling # та же программа с разными опциями.
% makepp -R ../my_program_source A_CFLAGS = -O2
% CD ..
% time no-unrolling / my_program # Сравните две версии программы.
% time my_program_source / my_program

Makepp действует так же, как и раньше, создавая ссылку на копию make-файла и затем исследуя объект.
файлы. Теперь необходимо перекомпилировать только модуль «ao», поскольку параметры «bo» и «co»
не изменилось. Makepp замечает, что он может использовать «bo» и «co» из репозитория, поэтому
он просто связывает их внутри. Однако он перекомпилирует "ao" в каталог "без разворачивания".
После завершения компиляции две разные версии программы могут быть
протестировано.

Восстановление a небольшая модификация в источник

Теперь предположим, что мы хотим внести изменения в "ac" и протестировать программу до и после
перемена. Репозитории снова могут помочь. Рассмотрим эту последовательность команд:

% mkdir модифицировано-а
% cp my_program_source / ac изменено-a
% модифицированный cd-a
% emacs ac # Внесите некоторые изменения только в этот модуль.
% makepp -R ../моя_программа_источник

Здесь мы создали новый каталог, который содержит единственный исходный файл, который мы хотим
изменить. Makepp теперь берет "ac" из подкаталога "modified-a", но использует копии
«b» и «c» из каталога «my_program_source». Без изменения какого-либо двоичного файла
файлы в "my_program_source", мы создали отдельную копию программы, которая
включает наши изменения в «ac». Если есть другие разработчики, использующие исходники в
"my_program_source", наши изменения не повлияют на них.

Таким образом, репозитории можно использовать как быстрый способ создания вариантов программы без
добавление сложных условий в make-файл. Ни один из файлов в оригинале
каталог изменен; они используются по мере необходимости.

. a каталог иерархия

На самом деле репозиторий - это не просто отдельный каталог, это целая иерархия каталогов.
Предположим, вы используете / наша / библиотека как репозиторий. Теперь / наша / библиотека вполне может содержать много
подкаталоги, например, / наша / библиотека / графический интерфейс и / наша / библиотека / сеть. Рассмотрим эту команду:

% makepp -R / наша / библиотека

Любые команды в make-файле, которые относятся к файлам в каталоге. ./сеть на самом деле будет
получить файлы из / наша / библиотека / сеть, и аналогично для ./интерфейс. Makepp автоматически
создает любые каталоги, которые существуют в репозитории, но не в текущем каталоге.

Связывающий в любое место in файл система

Во всех приведенных выше примерах показаны файлы из репозитория, связанные с текущим
каталог или его подкаталоги, но вы можете заставить makepp связать их в любом месте
в файловой системе, к которой у вас есть доступ на запись. Это делается путем указания
"-R новое-местоположение = старое-местоположение".

Например, иногда немного утомительно набирать следующее:

альтернативная сборка mkdir
альтернативный компакт-диск
макияжп -Р ..

Все это можно сделать одной командой, например:

makepp -R alternate-build =. -F альтернативная сборка

«-F» или «-makeppfile» изменяют этот каталог перед загрузкой make-файла. Вы должны
укажите "-R" перед "-F". Обратите внимание, что в этом примере новое дерево сборки помещается внутри
репозиторий. Это не сработает, если вы воспользуетесь RootMakeppfile потому что makepp защищает
против вложенных деревьев. Также не рекомендуется использовать **, потому что если вы когда-нибудь построите
в репозитории он также найдет отредактированные и сгенерированные файлы в этом поддереве.

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

% makepp -R test-build/seescape=/src/seescape
-R test-build/HLib=/src/HLib
-R test-build/H5pp=/src/H5pp
-R qwt=/источник/внешние_библиотеки/qwt
-F тестовая сборка / видение

Эта команда загружает файлы из четырех разных репозиториев, а затем создает компакт-диски в
./тестовая сборка/seescape каталог и запускает там make-файл. Файлы, содержащиеся в
дерево каталогов, начинающееся с / SRC / Seecape связаны с ./тестовая сборка/seescape. В
другими словами, makepp временно свяжет файл /src/seescape/gui/image_canvas.cxx в
./test-build/seescape/gui/image_canvas.cxx когда это необходимо. Эта команда будет работать даже
если каталог "test-build" еще не существует; makepp создаст его за вас. (Но ты
необходимо указать параметры «-R» перед параметром «-F» в командной строке.)

Многочисленные эквивалент хранилища

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

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

$ makepp -R / путь / к / группе / репозиторию -R / путь / к / производству / репозиторию

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

-R / путь / к / группе / репозиторию -R / путь / к / производству / репозиторию

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

репозиторий / путь / к / производству / репозиторию

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

$ makepp -R / путь / к / группе / репозиторию

Хранилища as фиксированной of строить система

Если вы знаете, что всегда используете какой-либо репозиторий, вы можете использовать «репозиторий» или «vpath».
операторы в вашем make-файле.

Предостережения хранилища
После появления связи получить in путь

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

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

Есть несколько тактик, чтобы преодолеть это:

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

· Не забудьте удалить любой файл, прежде чем создавать копию для записи. Если вы будете следовать
защитное предложение выше, если вы забудете сделать это, появится сообщение об ошибке, когда
пишу. Чтобы помочь вам, следующая функция «удалить ссылку» заменит одну ссылку копией
связанного файла. Первый вариант подходит для всех видов бурниш-панцирей, второй
один для csh (или хотя бы tcsh):

$ delink () {{rm $ 1 && cat> $ 1; } <$ 1; }
% alias delink '(rm \ !: 1 && cat> \ !: 1;) <\ !: 1'

· Если вы чувствуете, что они вам не нужны, вы можете удалить их все, когда захотите, например
после каждого запуска makepp, возможно, в фоновом режиме (короткая или длинная форма):

makeppclean --recurse --только ссылки на репозиторий
mppc -rR

не строить in a хранилище в течение используют

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

Если вам нужен репозиторий, который меняется по мере сборки, вы можете рассмотреть возможность использования makepp
механизм кеширования сборки (см. makepp_build_cache). В качестве альтернативы вы можете использовать "бедный человек"
репозиторий ": вы можете указать явные правила в свой make-файл для создания программных ссылок, например
это:

% .c: $ (каталог_I_wish_was_a_repository) /%. c
& ln -fs $ (ввод) $ (вывод)

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

Используйте Важно относительный имена файлов

Репозитории работают полностью прозрачно if Makefiles используют Важно относительный имена файлов.
В приведенном выше примере это нормально, если make-файл в / SRC / Seecape относится к ../HLib, Но
указанная выше команда не будет работать должным образом, если она относится к / src / HLib. Если вам нужно использовать
абсолютные имена файлов, вы можете поместить их в переменные make, а затем переопределить их в
командная строка, например:

% makepp -R test-build/seescape=/src/seescape SEESCAPE=/home/holt/test-build/seescape
-R test-build/HLib=/src/HLib HLIB=/home/holt/test-build/HLib
-R test-build/H5pp=/src/H5pp H5pp=/home/holt/test-build/H5pp
-R qwt=/источник/внешние_библиотеки/qwt QWT=/домашняя/holt/test-build/qwt
-F тестовая сборка / видение

Вышеупомянутое будет работать до тех пор, пока каталог «HLib» будет обозначаться как «$ (HLIB)» во всех
make-файлы. Обратите внимание, что вы должны указать абсолютные пути для каталогов, потому что
Сделайте компакт-диск makepp в "test-build / Seecape" перед чтением make-файла. Это приводит к долгому и
сложные команды make; по возможности используйте относительные пути.

Макепп обязательно знают о ВСЕ Зависимости

Репозитории не будут работать, если есть скрытые зависимости, о которых makepp не знает.
о. (Фактически, сборка с использованием репозиториев - это один из способов проверки забытых
зависимости. Но только для этой проверки не объединяйте его с кешем сборки, так как
получение чего-либо там, вместо того, чтобы создавать это, может скрыть забытую зависимость.)
Иногда эти зависимости могут быть довольно тонкими. Например, Libtool команда будет
не только создает файлы ".lo" и ".la", как указано в командной строке, но также может
создайте подкаталог с именем ".libs", содержащий фактические объектные файлы. Предотвращать
ошибки сборки, makepp отказывается ссылаться на файл ".la" из репозитория. Надеюсь, в
Будущий libtool будет лучше поддерживаться.

Многие скрытые зависимости, связанные с компиляцией, обнаруживаются сканером командной строки.
Если ваш компилятор использует общие флаги компиляции Unix (например, «-I», «-D» и т. Д.), Тогда
makepp обычно выясняет, где находятся все ваши включаемые файлы. Возможно, тебе придется быть
будьте осторожны, если у вас есть собственные скрипты, которые создают файлы, о которых makepp не знает.
о. Для правильной сборки жизненно важно перечислить ВСЕ цели и зависимости
(или определить их автоматически путем сканирования).

Полагая абсолютный имена файлов в программы

Репозитории также не будут работать, если какой-либо из созданных файлов содержит абсолютные имена файлов в
их (например, если какая-либо из ваших команд сборки записывает абсолютное имя файла). Например,
оказывается, что файлы ".la", созданные Libtool есть это свойство. (Если вы посмотрите на
содержимое файла ".la" вы увидите, что список зависимостей содержит абсолютные
имена файлов.) Чтобы решить эту конкретную проблему, makepp не будет связывать файлы ".la"
из репозитория; он будет настаивать на их восстановлении.

Избежать связывающий in ненужный каталоги

Репозитории могут работать медленно при запуске и использовать много памяти, если много
ненужные файлы в репозитории. Например, если вы используете автоматический HTML
генератор документации, который создает тысячи файлов ".html" из исходного кода, вы
может не захотеть помещать их в подкаталог каталога, который используется в качестве репозитория.
Лучше поместить их полностью в другое дерево каталогов, чтобы репозиторий
механизм не загружается в их имена.

Слишком Много Файлы

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

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

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

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

chmod a-rw исключаемый файл

Это предотвратит включение makepp из репозитория. Makepp также включает
специальный код, чтобы нечитаемые файлы не соответствовали шаблонным правилам или шаблонам.

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

Другой способ сделать это - вызвать makepp с одним или несколькими вариантами исключения:

mpp -R / путь / к / rep --dont-read = / путь / к / rep / исключаемый файл

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

# makefile верхнего уровня
репозиторий include = module1 / include
репозиторий include = module2 / include
репозиторий include = module3 / include
репозиторий include = module4 / include

Вероятно, это не лучшая идея, если любое .h файлы сами по себе являются выходом
программа (например, yacc или другая программа, которая выводит исходный код C), потому что makepp
предполагает, что файлы в репозиториях никогда не меняются. Если сборка требует включить / xyz.h и
модуль2 / включают / xyz.h на самом деле должно быть создано какой-то программой, makepp не будет знать
запустить программу. Лучше использовать такую ​​технику, чтобы .h файлов
в общий каталог include:

# module1 / Makeppfile
../include/%.h: включить /%. h
& cp $ (ввод) $ (вывод)
# Вы также можете (более эффективно, но проблематично в Windows) сделать следующее:
# & ln -r $ (ввод) $ (вывод)

Makepp все еще может попытаться собрать файлы, которые оказались в репозитории, если что-то спросит
для них напрямую, но он не будет их строить on от имени локального каталога. Результат
из-за этого может быть довольно запутанным, потому что это может привести к тому, что символическая ссылка репозитория будет
используется, пока его цель репозитория устарела, но эта цель может быть обновлена ​​позже
в сборке. Вы можете предотвратить это, убедившись, что
репозиторий упоминается Важно через путь к репозиторию или убедившись, что там
также является локальным правилом для всех сгенерированных файлов репозитория.

Другой способ избежать перекомпиляции одинаковых файлов в разных каталогах - использовать
построить кеш (подробности см. в makepp_build_cache). Кэш сборки не имеет
ограничение, что файл не может изменяться.

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