Dlaczego zawsze./ configure; make; make install; as 3 separate steps?

Po pierwsze, powinno być ./configure && make && make install ponieważ każdy zależy od sukcesu pierwszego. Po części powodem jest ewolucja, a po części wygoda dla przepływu pracy nad rozwojem.

Początkowo większość Makefile zawierałaby tylko polecenia kompilacji programu, a instalację pozostawiono użytkownikowi. Dodatkowa reguła pozwala make install umieścić skompilowane wyjście 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 być administrator systemu, nie chce go w ogóle instalować. Co więcej, jeśli rozwijam oprogramowanie, prawdopodobnie nie chcę go instalować. Chcę wprowadzić kilka zmian i przetestować wersję znajdującą się w moim katalogu. To staje się jeszcze bardziej istotne, jeśli mam zamiar mieć wiele wersji leżących wokół.

./configure goes i wykrywa, co jest dostępne w środowisku i / lub jest pożądane przez użytkownika, aby określić, jak zbudować oprogramowanie. Nie jest to coś, co musi się bardzo często zmieniać i często może to zająć trochę czasu. Ponownie, jeśli jestem programistą, nie warto poświęcać czasu na ciągłe rekonfigurowanie. Co ważniejsze, ponieważ {[4] } używa znaczników czasu do odbudowy modułów, jeśli ponownie uruchomię configure istnieje możliwość, że flagi się zmienią i teraz niektóre komponenty w mojej kompilacji będą kompilowane z jednym zestawem FLAG, a inne z innym zestawem flag, które mogą prowadzić do innego, niezgodnego zachowania. Dopóki nie uruchamiam ponownie configure, wiem, że moje środowisko kompilacji pozostaje takie samo nawet jeśli zmienię źródła. Jeśli powtórzę configure, powinienem make clean najpierw usunąć wszelkie wbudowane źródła, aby upewnić się, że rzeczy są zbudowane jednolicie.

Jedynym przypadkiem, w którym trzy polecenia są uruchamiane z rzędu, jest zainstalowanie programu przez użytkowników lub zbudowanie pakietu (np. Debian 's debuild lub RedHat' s rpmbuild). I to zakłada, że pakiet może mieć zwykły configure, co zwykle nie ma miejsca w przypadku opakowania, gdzie, co najmniej, --prefix=/usr jest pożądane. A pacakgers są jak mieć do czynienia z fake-roots podczas wykonywania make install części. Ponieważ istnieje wiele wyjątków, tworzenie ./configure && make && make install reguły byłoby niewygodne dla wielu osób, które robią to znacznie częściej!

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

make uruchamia domyślny cel, pierwszy wymieniony w pliku Makefile. Często celem jest all, ale nie zawsze. Więc mógłbyś tylko make all install, 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 włączone, ponieważ często trzeba podać opcje do configure.

Ale dlaczego po prostu nie pozwolić ludziom zrobić to sami? Czy to naprawdę taka wielka wygrana?

Po pierwsze ./ configure nie zawsze znajduje wszystko, czego potrzebuje, lub w innych przypadkach znajduje wszystko, czego potrzebuje, ale nie wszystko, czego może użyć. W takim przypadku chciałbyś o tym wiedzieć (i twój ./install.sh scenariusz i tak by się nie powiódł!) Klasycznym przykładem braku awarii z niezamierzonymi konsekwencjami, z mojego punktu widzenia, jest kompilacja dużych aplikacji, takich jak ffmpeg czy mplayer. Będą one używać bibliotek, jeśli są one dostępne, ale i tak będą kompilowane, jeśli nie są, pozostawiając niektóre opcje wyłączone. Problem polega na tym, że później odkryjesz, że został skompilowany bez wsparcia dla jakiegoś formatu lub innego, co wymaga powrotu i ponownego wykonania go.

Inna sprawa ./ configure robi nieco interaktywnie daje możliwość dostosowania gdzie w systemie aplikacja zostanie zainstalowana. Różne dystrybucje / środowiska mają różne konwencje i prawdopodobnie chciałbyś trzymać się konwencji w swoim systemie. Możesz również zainstalować to lokalnie (wyłącznie dla siebie). Tradycyjnie ./ configure and make kroki nie są uruchamiane jako root, podczas gdy make install (chyba że jest zainstalowany wyłącznie dla siebie) musi być uruchamiane jako root.

Określone dystrybucje często dostarczają skrypty, które to wykonują ./install.sh funkcjonalność w sposób wrażliwy na dystrybucję - na przykład źródło RPMs + plik spec + rpmbuildlub slackbuilds.

(przypis: to powiedziawszy, zgadzam się z tym ./ configure; make; make install; może być bardzo uciążliwe.)