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

во-первых, он должен быть!--0--> с каждого зависит от успеха первого. Часть причины-это эволюция, а часть причины-удобство для рабочего процесса разработки.

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

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

единственный случай, когда три команды выполняются подряд, - это когда пользователи устанавливают программу или создается пакет (например, debuild Debian или rpmbuild RedHat). И это предполагает, что пакет может быть дан простой configure, что обычно не относится к упаковке, где, по крайней мере,--prefix=/usr желательно. И pacakgers, как иметь дело с поддельными корнями при выполнении make install часть. Так как есть много исключений, делая ./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

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

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

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

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

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

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