Почему всегда ./configure; делать; сделать установку; как 3 отдельных шага?

Каждый раз, когда вы компилируете что-то из исходного кода, вы выполняете те же 3 шага:

$ ./configure
$ make
$ make install

Я понимаю, что имеет смысл разделить процесс установки на разные этапы, но я не понимаю, почему каждый кодер на этой планете должен снова и снова писать одни и те же три команды, чтобы выполнить одну единственную работу. С моей точки зрения, было бы вполне разумно, если бы ./install.shсценарий автоматически доставлялся с исходным кодом, который содержит следующий текст:

#!/bin/sh
./configure
make
make install

почему люди должны делать 3 шага отдельно?

Потому что каждый шаг делает разные вещи

Подготовить (настроить) среду для сборки

./configure

В этом скрипте есть множество опций, которые вам следует изменить. Вроде --prefixили --with-dir=/foo. Это означает, что каждая система имеет свою конфигурацию. Также ./configureпроверяет наличие недостающих библиотек, которые необходимо установить. Если здесь что-то не так, ваше приложение не будет создано . Вот почему в дистрибутивах есть пакеты, которые устанавливаются в разных местах, потому что каждый дистрибутив считает, что лучше устанавливать определенные библиотеки и файлы в определенные каталоги. Говорят, что он работает ./configure, но на самом деле его следует менять всегда.

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

Построение системы

make

Это на самом деле make all по умолчанию. И у каждой модели есть свои действия. Кто-то занимается сборкой, кто-то тестирует после сборки, кто-то проверяет данные из внешних репозиториев SCM. Обычно вам не нужно указывать какие-либо параметры, но, опять же, некоторые пакеты выполняют их по-другому.

Установить в систему

make install

Это устанавливает пакет в место, указанное с помощью configure. Если вы хотите, вы можете указать ./configureссылку на свой домашний каталог. Однако многие параметры настройки указывают на /usrили /usr/local. Это означает, что вы должны использовать его, sudo make installпотому что только root может копировать файлы в / usr и / usr / local.

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

Здесь вы увидите, что каждый шаг на самом деле является отдельным состоянием. Вот почему у менеджеров пакетов разные обертки. Ниже приведен пример оболочки, которая позволяет вам собрать весь пакет за один шаг. Но помните, что у каждого приложения есть своя оболочка (на самом деле эти оболочки имеют такие имена, как spec, PKGBUILD и т. Д.):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

Здесь можно использовать автоинструменты, то есть ./configure, makeи make install. Но другой может использовать SCons, настройку, связанную с Python, или что-то другое.

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

Во-первых, это должно быть ./configure && make && make install поскольку каждый зависит от успеха первого. Отчасти причина - в эволюции, а отчасти - в удобстве рабочего процесса разработки.

Первоначально большинство Makefiles содержали только команды для компиляции программы, а установка оставалась на усмотрение пользователя. Дополнительное правило позволяет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если бы знали, что это цель.

Так ...

#!/bin/sh

if ./configure $*; then
  if make; then
    make install
  fi
fi

или:

./configure $* && ./make && ./make install

$*Включен , потому что часто приходится предоставлять возможности для configure.

Но почему бы просто не позволить людям делать это самим? Неужели это такая большая победа?