Чому завжди ./конфігурувати; зробити; зробити встановлення; як 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ваш домашній каталог. Однак багато параметрів налаштування вказують на /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

Тут можна використовувати автоінструменти, це означає ./configure, makeі make install. Але інший може використовувати SCON, налаштування, пов'язані з Python, або щось інше.

Як бачите, розщеплення кожної держави значно полегшує підтримку та розгортання, особливо для обслуговуючого пакета та дистрибутива.

По-перше, це має бути, ./configure && make && make installоскільки від кожного залежить успіх колишнього. Частина причини - це еволюція, а частина - зручність для робочого процесу розвитку.

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

./configureйде і виявляє, що є в середовищі та / або бажає користувач, щоб визначити, як створити програмне забезпечення. Це не те, що потрібно змінювати дуже часто і часто може зайняти деякий час. Знову ж таки, якщо я розробник, не варто постійно переналаштовувати. Що ще важливіше, оскільки makeвикористовуються часові позначки для відновлення модулів, якщо я повторюсь configure, є можливість зміни прапорів, і тепер деякі компоненти в моїй збірці будуть компільовані з одним набором прапорів, а інші з іншим набором прапорів, які можуть призвести до інша, несумісна поведінка. Поки я не повторююся configure, я знаю, що моє середовище компіляції залишається таким же, навіть якщо я міняю свої джерела. Якщо я повторюся configure, я повинен бувmake clean по-перше, видалити будь-які вбудовані джерела, щоб забезпечити рівномірність побудови речей.

Єдиний випадок, коли три команди виконуються підряд, це коли користувачі встановлюють програму або будується пакет (наприклад, Debuild's debuild або RedHat's rpmbuild). І це передбачає, що упаковці можна надати звичайну configure, що зазвичай не стосується упаковки, де, принаймні, --prefix=/usrбажано. І пікантним людям подобається мати справу з підробленими корінцями, виконуючи make installроль. Оскільки існує маса винятків, зробити ./configure && make && make installправило було б незручно для багатьох людей, які роблять це набагато частіше!

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

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

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

(Зноска: якщо говорити, я згоден, що ./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.

Але чому б просто не дати людям робити це самі? Це справді такий великий виграш?