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

118

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?

erikbwork
źródło
2
Jeśli system kompilacji jest napisany poprawnie - a zwykle tak jest - możesz pominąć drugi krok.
reinierpost
Twoje pytanie nie jest głupie. Możesz zbudować swój program w środowisku Linux, a następnie możesz go używać przez jakąś aplikację do wirtualizacji lub możesz budować bezpośrednio w środowisku Windows przy użyciu mingw.
Mihai8

Odpowiedzi:

121

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.

Fatih Arslan
źródło
23
Czytając to ponownie, około rok później, muszę dodać, że to wszystko ma sens, a mimo to może istnieć jedno wywołanie polecenia, które wykonuje wszystkie 3 kroki z ich domyślną konfiguracją. Wszystkie mają domyślną konfigurację, w przeciwnym razie nie można by ich po prostu wywołać bez argumentów.
erikbwork
Czasami mogę wykonać instalację bez tworzenia. Co to znaczy? Jeśli pominę make, mogę po prostu zrobić instalację?
CMCDragonkai
3
installzależy od w allzwiązku z tym make installzadzwonięmake all
doskonała odpowiedź, jednak nie rozumiem, dlaczego czasami wymagana jest instalacja make install, a innym razem nie (jedna marka, zrób całą magię)
HanniBaL90
make installwystarczy zainstalować różne zasoby we wstępnie zdefiniowanej lokalizacji. Jeśli zależy Ci tylko na pliku wykonywalnym, możesz użyć pliku wykonywalnego z katalogu kompilacji i dodać katalog kompilacji do swojej PATH.
jdhao,
31

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!

apmasell
źródło
2
Dzięki za poradę &&!
erikbwork
4

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.)

Soz
źródło
Wszystko zrozumiałe, ale w moich oczach żadna z tych możliwości nie jest zniszczona, jeśli masz jeden dodatkowy plik, który łączy te trzy kroki. Np. Jeśli chcesz przeczytać część konfiguracyjnego standardowego wyjścia, możesz nadal grep dla niego lub umieścić całe standardowe wyjście do pliku i przeczytać go później.
erikbwork
3
To prawda, ale w takim razie dlaczego plik jest wymagany? Po prostu użyj aliasu (chociaż będziesz musiał wymyślić lepszą / krótszą nazwę niż „confmakeins”, dziś nie mam natchnienia!). alias confmakeins = '. / configure && make && sudo make install'; katalog źródłowy cd; confmakeins;
Soz
Brzmi dobrze. Sam nigdy nie pisałem aliasu, więc nie myślałem o tym!
erikbwork
3

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?

ghoti
źródło
1
To nie jest śmiertelnie ważne, ale chodzi o to, co robimy my, programiści: zmuszanie komputera do wykonywania za nas powtarzalnych zadań. Dobrze?
erikbwork
1
Cóż ... configurejest częścią zestawu narzędzi GNU Automake, który jest swego rodzaju dodatkiem do Make. Make istnieje od wielu lat i dobrze spełnia swoje zadanie. To powiedziawszy, ludzie wymyślili inne sposoby obsługi procesu tworzenia. Ant i cmake mają swoich zwolenników. Jednak wszystkie części procesu budowania (takie jak konfigurowanie, budowanie i instalowanie) to nadal oddzielne polecenia.
ghoti