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

118

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

$ ./configure
$ make
$ make install

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

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

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

erikbwork
источник
2
Если система сборки написана правильно - а это обычно так - вы можете пропустить второй шаг.
reinierpost
Ваш вопрос не глупый. Вы можете создать свою программу в среде Linux, и после этого вы можете использовать ее в каком-либо приложении виртуализации, или вы можете построить непосредственно в среде Windows с помощью mingw.
Mihai8

Ответы:

121

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

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

./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, или что-то другое.

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

Фатих Арслан
источник
23
Прочитав это еще раз, примерно год спустя, я должен добавить, что все это имеет смысл, и все же может быть один вызов команды, который выполняет все 3 шага с их конфигурацией по умолчанию. Все они имеют конфигурацию по умолчанию, иначе вы не могли бы просто вызвать их без аргументов.
erikbwork
Иногда я могу сделать установку без make. Что это значит? Если я пропущу make, я смогу просто выполнить make install?
CMCDragonkai
3
installзависит от allпоэтому make installпозвонюmake all
отличный ответ, однако я не понимаю, почему иногда требуется make install, а иногда нет (один make, все волшебство)
HanniBaL90
make installпросто установите различные ресурсы в заранее определенное место. Если вас интересует только исполняемый файл, вы можете использовать исполняемый файл из каталога сборки и добавить каталог сборки в свой PATH.
jdhao 07
31

Во-первых, это должно быть ./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правила будет неудобно для многих людей, которые делают это гораздо чаще!

apmasell
источник
2
Спасибо за совет &&!
erikbwork 09
4

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

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

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

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

соз
источник
Все понятно, но, на мой взгляд, ни одна из этих возможностей не будет уничтожена, если у вас есть один дополнительный файл, объединяющий три шага. Например, если вы хотите прочитать некоторые настройки stdout, вы все равно можете использовать их с помощью grep или поместить весь стандартный вывод в файл и потом прочитать его.
erikbwork 09
3
Верно, но тогда зачем нужен файл? Просто используйте псевдоним (хотя вам придется придумать имя лучше / короче, чем «confmakeins», меня сегодня это не вдохновляет!). псевдоним confmakeins = '. / configure && make && sudo make install'; cd исходный каталог; confmakeins;
Соз
Звучит хорошо. Сам я никогда не писал псевдонимы, поэтому не думал об этом!
erikbwork 09
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.

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

Ghoti
источник
1
Это не смертельно важно, но дело в том, что мы, программисты, делаем: заставляем компьютер выполнять повторяющиеся задачи за нас. Правильно?
erikbwork 09
1
Ну ... configureэто часть инструментария GNU Automake, который является своего рода надстройкой к Make. Make существует уже много-много лет и хорошо выполняет свою работу. Тем не менее, люди придумали другие способы управления процессом создания. У Ant и cmake есть свои последователи. Но части процесса сборки (например, настройка, сборка и установка) по-прежнему являются отдельными командами.
ghoti