Каждый раз, когда вы компилируете что-то из исходного кода, вы выполняете те же 3 шага:
$ ./configure
$ make
$ make install
Я понимаю, что имеет смысл разделить процесс установки на разные этапы, но я не понимаю, почему каждый кодер на этой планете должен снова и снова писать одни и те же три команды, чтобы выполнить одну единственную работу. С моей точки зрения, было бы вполне разумно, если бы ./install.sh
сценарий автоматически доставлялся с исходным кодом, который содержит следующий текст:
#!/bin/sh
./configure
make
make install
почему люди должны делать 3 шага отдельно?
unix
makefile
configure
make-install
erikbwork
источник
источник
Ответы:
Потому что каждый шаг делает разные вещи
Подготовить (настроить) среду для сборки
В этом скрипте есть множество опций, которые вам следует изменить. Вроде
--prefix
или--with-dir=/foo
. Это означает, что каждая система имеет свою конфигурацию. Также./configure
проверяет наличие недостающих библиотек, которые необходимо установить. Если здесь что-то не так, ваше приложение не будет создано . Вот почему в дистрибутивах есть пакеты, которые устанавливаются в разных местах, потому что каждый дистрибутив считает, что лучше устанавливать определенные библиотеки и файлы в определенные каталоги. Говорят, что он работает./configure
, но на самом деле его следует менять всегда.Например, посмотрите сайт пакетов Arch Linux . Здесь вы увидите, что любой пакет использует другой параметр конфигурации (предположим, что они используют автоинструменты для системы сборки).
Построение системы
Это на самом деле
make all
по умолчанию. И у каждой модели есть свои действия. Кто-то занимается сборкой, кто-то тестирует после сборки, кто-то проверяет данные из внешних репозиториев SCM. Обычно вам не нужно указывать какие-либо параметры, но, опять же, некоторые пакеты выполняют их по-другому.Установить в систему
Это устанавливает пакет в место, указанное с помощью configure. Если вы хотите, вы можете указать
./configure
ссылку на свой домашний каталог. Однако многие параметры настройки указывают на/usr
или/usr/local
. Это означает, что вы должны использовать его,sudo make install
потому что только root может копировать файлы в / usr и / usr / local.Теперь вы видите, что каждый шаг является предварительным требованием для следующего шага. Каждый шаг - это подготовка к тому, чтобы все работало беспроблемно. Дистрибутивы используют эту метафору для создания пакетов (например, RPM, deb и т. Д.).
Здесь вы увидите, что каждый шаг на самом деле является отдельным состоянием. Вот почему у менеджеров пакетов разные обертки. Ниже приведен пример оболочки, которая позволяет вам собрать весь пакет за один шаг. Но помните, что у каждого приложения есть своя оболочка (на самом деле эти оболочки имеют такие имена, как spec, PKGBUILD и т. Д.):
Здесь можно использовать автоинструменты, то есть
./configure
,make
иmake install
. Но другой может использовать SCons, настройку, связанную с Python, или что-то другое.Как видите, разделение каждого состояния значительно упрощает обслуживание и развертывание, особенно для разработчиков пакетов и дистрибутивов.
источник
install
зависит отall
поэтомуmake install
позвонюmake all
make install
просто установите различные ресурсы в заранее определенное место. Если вас интересует только исполняемый файл, вы можете использовать исполняемый файл из каталога сборки и добавить каталог сборки в свой PATH.Во-первых, это должно быть
./configure && make && make install
поскольку каждый зависит от успеха первого. Отчасти причина - в эволюции, а отчасти - в удобстве рабочего процесса разработки.Первоначально большинство
Makefile
s содержали только команды для компиляции программы, а установка оставалась на усмотрение пользователя. Дополнительное правило позволяетmake install
разместить скомпилированный вывод в том месте, которое может быть правильным; есть еще много веских причин, по которым вы, возможно, не захотите этого делать, включая то, что вы не являетесь системным администратором, или вообще не хотите устанавливать его. Более того, если я занимаюсь разработкой программного обеспечения, я, вероятно, не хочу его устанавливать. Я хочу внести некоторые изменения и протестировать версию, находящуюся в моем каталоге. Это становится еще более заметным, если у меня будет несколько версий../configure
идет и обнаруживает, что доступно в среде и / или что требуется пользователю, чтобы определить, как построить программное обеспечение. Это не то, что нужно менять очень часто и часто может занять некоторое время. Опять же, если я разработчик, не стоит тратить время на постоянную перенастройку. Что еще более важно, посколькуmake
для перестройки модулей используются временные метки, при повторном запускеconfigure
есть вероятность, что флаги изменятся, и теперь некоторые компоненты в моей сборке будут скомпилированы с одним набором флагов, а другие - с другим набором флагов, что может привести к разное, несовместимое поведение. Пока я не выполняю повторный запускconfigure
, я знаю, что моя среда компиляции остается прежней, даже если я изменю свои источники. Если я побегуconfigure
, я долженmake clean
во-первых, удалить все встроенные источники, чтобы все было построено единообразно.Единственный случай, когда три команды запускаются подряд, - это когда пользователи устанавливают программу или собирается пакет (например, debuild Debian или rpmbuild RedHat). И это предполагает, что упаковка может быть простой
configure
, что обычно не относится к упаковке, где, по крайней мере,--prefix=/usr
желательно. И пакакгеры любят иметь дело с фальшивыми корнями при выполнении своей ролиmake install
. Поскольку существует множество исключений, создание./configure && make && make install
правила будет неудобно для многих людей, которые делают это гораздо чаще!источник
&&
!Во-первых ./configure не всегда находит все, что ему нужно, или, в других случаях, находит все, что ему нужно, но не все, что можно использовать. В этом случае вы захотите узнать об этом (и ваш скрипт ./install.sh все равно не сработает!) Классическим примером отсутствия сбоя с непредвиденными последствиями, с моей точки зрения, является компиляция больших приложений, таких как ffmpeg или mplayer. Они будут использовать библиотеки, если они доступны, но все равно будут компилироваться, если их нет, оставив некоторые параметры отключенными. Проблема в том, что позже вы обнаружите, что он был скомпилирован без поддержки того или иного формата, поэтому вам нужно вернуться и переделать его.
Еще одна вещь, которую ./configure делает в некоторой степени интерактивно, дает вам возможность настроить, где в системе будет установлено приложение. Разные дистрибутивы / среды имеют разные соглашения, и вы, вероятно, захотите придерживаться соглашения в своей системе. Кроме того, вы можете установить его локально (исключительно для себя). Обычно шаги ./configure и make запускаются не от имени root, а make install (если она не установлена исключительно для вас) должна запускаться от имени root.
Конкретные дистрибутивы часто предоставляют сценарии, которые выполняют эту функцию ./install.sh в зависимости от распространения - например, исходные RPM + файл спецификации + rpmbuild или slackbuild .
(Сноска: при этом я согласен с тем, что ./configure; make; make install; может быть чрезвычайно утомительным.)
источник
configure
может потерпеть неудачу, если обнаружит, что зависимости отсутствуют.make
запускает цель по умолчанию, первую из перечисленных в Makefile. Часто это цельall
, но не всегда. Так что вы могли бы, толькоmake all install
если бы знали, что это цель.Так ...
или:
$*
Включен , потому что часто приходится предоставлять возможности дляconfigure
.Но почему бы просто не позволить людям делать это самим? Неужели это такая большая победа?
источник
configure
это часть инструментария GNU Automake, который является своего рода надстройкой к Make. Make существует уже много-много лет и хорошо выполняет свою работу. Тем не менее, люди придумали другие способы управления процессом создания. У Ant и cmake есть свои последователи. Но части процесса сборки (например, настройка, сборка и установка) по-прежнему являются отдельными командами.