Dlaczego zawsze ./configure; robić; dokonać instalacji; jako 3 oddzielne kroki?

Za każdym razem, gdy kompilujesz coś ze źródła, przechodzisz przez te same 3 kroki:

$ ./configure
$ make
$ make install

Rozumiem, że warto podzielić proces instalacji na różne etapy, ale nie rozumiem, dlaczego każdy koder na tej planecie musi raz po raz pisać te same trzy polecenia, aby wykonać jedną pracę. Z mojego punktu widzenia całkowicie sensowne byłoby, gdyby ./install.shskrypt był automatycznie dostarczany z kodem źródłowym zawierającym następujący tekst:

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

dlaczego ludzie mieliby wykonywać te 3 kroki oddzielnie?

Ponieważ każdy krok ma inne znaczenie

Przygotuj (skonfiguruj) środowisko do budowania

./configure

Ten skrypt ma wiele opcji, które powinieneś zmienić. Like --prefixlub --with-dir=/foo. Oznacza to, że każdy system ma inną konfigurację. ./configureSprawdza również brakujące biblioteki, które powinny zostać zainstalowane. Cokolwiek tu jest nie tak, powoduje, że aplikacja nie jest tworzona . Dlatego dystrybucje mają pakiety, które są instalowane w różnych miejscach, ponieważ każda dystrybucja uważa, że ​​lepiej jest zainstalować określone biblioteki i pliki w określonych katalogach. Mówi się, że działa ./configure, ale w rzeczywistości należy to zawsze zmieniać.

Na przykład spójrz na witrynę pakietów Arch Linux . Tutaj zobaczysz, że każdy pakiet używa innego parametru konfiguracji (załóżmy, że używają narzędzi automatycznych dla systemu kompilacji).

Budowanie systemu

make

W rzeczywistości jest to make allustawienie domyślne. Każda marka ma inne czynności do wykonania. Niektórzy budują, niektórzy wykonują testy po zbudowaniu, niektórzy robią zakupy z zewnętrznych repozytoriów SCM. Zwykle nie musisz podawać żadnych parametrów, ale znowu niektóre pakiety wykonują je inaczej.

Zainstaluj w systemie

make install

Spowoduje to zainstalowanie pakietu w miejscu określonym w pliku configure. Jeśli chcesz, możesz wskazać ./configurekatalog domowy. Jednak wiele opcji konfiguracyjnych wskazuje na /usrlub /usr/local. Oznacza to, że musisz użyć faktycznie, sudo make installponieważ tylko root może kopiować pliki do / usr i / usr / local.

Teraz widzisz, że każdy krok jest warunkiem wstępnym następnego kroku. Każdy krok jest przygotowaniem do bezproblemowego przepływu rzeczy. Dystrybucje używają tej metafory do tworzenia pakietów (takich jak RPM, deb itp.).

Tutaj zobaczysz, że każdy krok jest w rzeczywistości innym stanem. Dlatego menedżerowie pakietów mają różne opakowania. Poniżej znajduje się przykład opakowania, które pozwala zbudować cały pakiet w jednym kroku. Pamiętaj jednak, że każda aplikacja ma inne opakowanie (w rzeczywistości te opakowania mają takie nazwy jak specyfikacja, PKGBUILD itp.):

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

Można tu korzystać z autotools, co oznacza ./configure, makei make install. Ale inny może użyć SCons, konfiguracji związanej z Pythonem lub czegoś innego.

Jak widać, podzielenie każdego stanu znacznie ułatwia konserwację i wdrażanie, szczególnie dla opiekunów pakietów i dystrybucji.

Po pierwsze, powinno ./configure && make && make install ponieważ każdy zależy od sukcesu tego pierwszego. Jednym z powodów jest ewolucja, a częściowo wygoda przepływu pracy podczas tworzenia oprogramowania.

Początkowo większość Makefiles zawierała tylko polecenia kompilacji programu, a instalację pozostawiano użytkownikowi. Dodatkowa reguła pozwalamake install na umieszczenie skompilowanego wyniku w miejscu, które może być poprawne; nadal istnieje wiele dobrych powodów, dla których możesz nie chcieć tego robić, w tym nie będąc administratorem systemu, w ogóle nie chcesz go instalować. Co więcej, jeśli tworzę oprogramowanie, prawdopodobnie nie chcę go instalować. Chcę wprowadzić pewne zmiany i przetestować wersję znajdującą się w moim katalogu. Staje się to jeszcze bardziej istotne, jeśli zamierzam mieć wiele wersji.

./configureidzie i wykrywa, co jest dostępne w środowisku i / lub jest pożądane przez użytkownika, aby określić, jak zbudować oprogramowanie. To nie jest coś, co musi się zmieniać bardzo często i często może zająć trochę czasu. Ponownie, jeśli jestem programistą, nie warto tracić czasu na ciągłą rekonfigurację. Co ważniejsze, ponieważ makeużywa znaczników czasu do przebudowy modułów, jeśli uruchomię ponownie, configureistnieje możliwość, że flagi się zmienią i teraz niektóre komponenty w mojej kompilacji zostaną skompilowane z jednym zestawem flag, a inne z innym zestawem flag, co może prowadzić do różne, niezgodne zachowanie. Dopóki nie uruchomię ponownie configure, wiem, że moje środowisko kompilacji pozostaje takie samo, nawet jeśli zmienię źródła. Jeśli uruchomię ponownie najpierw, aby usunąć wszelkie wbudowane źródła, aby upewnić się, że wszystko jest zbudowane jednolicie.configure , powinienemmake clean

Jedynym przypadkiem, w którym trzy polecenia są uruchamiane z rzędu, jest sytuacja, gdy użytkownicy instalują program lub budowany jest pakiet (np. Debuild Debiana lub rpmbuild RedHata). A to zakłada, że ​​opakowanie może otrzymać zwykły materiał configure, co zwykle nie ma miejsca w przypadku pakowania, jeśli przynajmniej --prefix=/usrjest to pożądane. A pacakirzy są jak mieć do czynienia z fałszywymi korzeniami podczas wykonywania roli make install. Ponieważ istnieje wiele wyjątków, ustalenie ./configure && make && make installreguły byłoby niewygodne dla wielu osób, które robią to znacznie częściej!

Po pierwsze ./configure nie zawsze znajduje wszystko, czego potrzebuje, lub w innych przypadkach znajduje wszystko, czego potrzebuje, ale nie wszystko, czego mógłby użyć. W takim przypadku chciałbyś o tym wiedzieć (a twój skrypt ./install.sh i tak by się nie udał!) Klasycznym przykładem niepowodzenia z niezamierzonymi konsekwencjami, z mojego punktu widzenia, jest kompilowanie dużych aplikacji, takich jak ffmpeg lub mplayer. Będą korzystać z bibliotek, jeśli są dostępne, ale i tak kompilują się, jeśli nie są, pozostawiając niektóre opcje wyłączone. Problem polega na tym, że później odkrywasz, że został skompilowany bez obsługi jakiegoś formatu, co wymaga cofnięcia się i ponownego wykonania.

Inną rzeczą, którą ./configure jest w pewnym stopniu interaktywnie, jest możliwość dostosowania miejsca w systemie, w którym aplikacja zostanie zainstalowana. Różne dystrybucje / środowiska mają różne konwencje i prawdopodobnie chciałbyś trzymać się konwencji w swoim systemie. Możesz też chcieć zainstalować go lokalnie (wyłącznie dla siebie). Tradycyjnie kroki ./configure i make nie są uruchamiane jako root, natomiast make install (chyba że jest instalowane wyłącznie dla ciebie) musi być uruchamiane jako root.

Określone dystrybucje często udostępniają skrypty, które wykonują tę funkcję ./install.sh w sposób uwzględniający dystrybucję - na przykład źródłowe pliki RPM + plik specyfikacji + rpmbuild lub slackbuilds .

(Przypis: to powiedziawszy, zgadzam się z tym ./configure; make; make install; może być bardzo nudne.)

configure może się nie powieść, jeśli stwierdzi, że brakuje zależności.

makeuruchamia domyślny cel, pierwszy wymieniony w pliku Makefile. Często jest to cel all, ale nie zawsze. Więc mógłbyś tylko make all installwtedy, gdybyś wiedział, że to był cel.

Więc ...

#!/bin/sh

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

lub:

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

Jest $*on uwzględniony, ponieważ często trzeba zapewnić opcje configure.

Ale dlaczego nie pozwolić ludziom robić tego sami? Czy to naprawdę taka wielka wygrana?