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.sh
skrypt 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?
unix
makefile
configure
make-install
erikbwork
źródło
źródło
Odpowiedzi:
Ponieważ każdy krok ma inne znaczenie
Przygotuj (skonfiguruj) środowisko do budowania
Ten skrypt ma wiele opcji, które powinieneś zmienić. Like
--prefix
lub--with-dir=/foo
. Oznacza to, że każdy system ma inną konfigurację../configure
Sprawdza 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
W rzeczywistości jest to
make all
ustawienie 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
Spowoduje to zainstalowanie pakietu w miejscu określonym w pliku configure. Jeśli chcesz, możesz wskazać
./configure
katalog domowy. Jednak wiele opcji konfiguracyjnych wskazuje na/usr
lub/usr/local
. Oznacza to, że musisz użyć faktycznie,sudo make install
ponieważ 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.):
Można tu korzystać z autotools, co oznacza
./configure
,make
imake 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.
źródło
install
zależy od wall
związku z tymmake install
zadzwonięmake all
make install
wystarczy 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.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ść
Makefile
s 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../configure
idzie 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żmake
używa znaczników czasu do przebudowy modułów, jeśli uruchomię ponownie,configure
istnieje 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ę ponownieconfigure
, 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=/usr
jest to pożądane. A pacakirzy są jak mieć do czynienia z fałszywymi korzeniami podczas wykonywania rolimake install
. Ponieważ istnieje wiele wyjątków, ustalenie./configure && make && make install
reguły byłoby niewygodne dla wielu osób, które robią to znacznie częściej!źródło
&&
!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.)
źródło
configure
może się nie powieść, jeśli stwierdzi, że brakuje zależności.make
uruchamia domyślny cel, pierwszy wymieniony w pliku Makefile. Często jest to celall
, ale nie zawsze. Więc mógłbyś tylkomake all install
wtedy, gdybyś wiedział, że to był cel.Więc ...
lub:
Jest
$*
on uwzględniony, ponieważ często trzeba zapewnić opcjeconfigure
.Ale dlaczego nie pozwolić ludziom robić tego sami? Czy to naprawdę taka wielka wygrana?
źródło
configure
jest 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.