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

Question

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

$ ./configure
$ make
$ make install

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

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

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

Answer 1

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

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

./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.

---

Теперь вы видите, что каждый шаг является предварительным требованием для следующего шага. Каждый шаг - это подготовка к тому, чтобы все работало без проблем. Distros использует эту метафору для сборки пакетов (например, 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

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

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

Answer 2

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

Первоначально большинство Makefiles будет содержать только команды для компиляции программы, и установка будет оставлена ​​на усмотрение пользователя. Дополнительное правило позволяет make install поместить скомпилированный вывод в место, которое может быть правильным; по-прежнему есть много веских причин, по которым вы, возможно, не захотите этого делать, включая то, что вы не являетесь системным администратором или вообще не хотите его устанавливать. Более того, если я занимаюсь разработкой программного обеспечения, я, вероятно, не хочу его устанавливать. Я хочу внести некоторые изменения и проверить версию в моем каталоге. Это становится еще более заметным, если я собираюсь разместить несколько версий.

./configure Идет и обнаруживает то, что доступно в среде и / или желательно пользователем, чтобы определить, как построить программное обеспечение. Это не то, что нужно менять очень часто и может занять некоторое время. Опять же, если я разработчик, не стоит тратить время на перенастройку. Что еще более важно, так как make использует временные метки для восстановления модулей, если я перезапущу configure есть вероятность, что флаги изменятся, и теперь некоторые компоненты в моей сборке будут скомпилированы с одним набором флагов, а другие с другим набором флагов, что может привести к другому, несовместимому поведению. Пока я не перезапущу configureЯ знаю, что моя среда компиляции остается неизменной, даже если я изменю свои источники. Если я перезапущу configure, Я должен make clean во-первых, чтобы удалить любые встроенные источники, чтобы гарантировать, что вещи построены равномерно.

Единственный случай, когда три команды выполняются подряд, - это когда пользователь устанавливает программу или создает пакет (например, Debian Debuild или RedHat Rpmbuild). И это предполагает, что пакет может быть дан простой configure, что обычно не относится к упаковке, где, по крайней мере, --prefix=/usr желательно И pacakgers, как будто приходится иметь дело с поддельными корнями, делая make install часть. Так как есть много исключений, делая ./configure && make && make install Правило было бы неудобно для многих людей, которые делают это гораздо чаще!

Answer 3

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

make запускает цель по умолчанию, первый из которых указан в Makefile. Часто эта цель all, но не всегда. Так что вы могли только make all install если бы вы знали, что это была цель.

Так...

#!/bin/sh

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

или же:

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

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

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

Answer 4

Во-первых,./configure не всегда находит все, что ему нужно, или в других случаях он находит все, что ему нужно, но не все, что он может использовать. В этом случае вы захотите узнать об этом (и ваш скрипт./install.sh в любом случае не удастся!). Классическим примером безотказности с непредвиденными последствиями, с моей точки зрения, является компиляция больших приложений, таких как ffmpeg или mplayer. Они будут использовать библиотеки, если они доступны, но все равно будут компилироваться, если они не доступны, оставляя некоторые опции отключенными. Проблема в том, что вы потом обнаружите, что он был скомпилирован без поддержки какого-либо формата или другого, поэтому вам нужно вернуться и повторить его.

Еще одна вещь./configure делает несколько интерактивно дает вам возможность настроить, где в системе будет установлено приложение. Разные дистрибутивы / среды имеют разные соглашения, и вы, вероятно, захотите придерживаться соглашения в вашей системе. Кроме того, вы можете установить его локально (исключительно для себя). Традиционно шаги./configure и make не запускаются от имени пользователя root, а make install (если он не установлен исключительно для вас) должен запускаться от имени пользователя root.

Конкретные дистрибутивы часто предоставляют сценарии, которые выполняют эту функцию./install.sh с учетом дистрибутива, например, исходные RPM + spec-файл + rpmbuild или slackbuilds.

(Сноска: при этом, я согласен, что./configure; make; make install; может стать чрезвычайно утомительным.)