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

Ответ 1

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

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

./configure

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

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

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

make

Это по умолчанию make all. И каждый make имеет разные действия. Некоторые делают строительство, некоторые делают тесты после строительства, некоторые делают проверку из внешних репозиториев 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 или что-то другое.

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

Ответ 2

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

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

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

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

Ответ 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.

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

Ответ 4

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

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

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

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