Pochodzące ze świata C i C ++ większość systemów kompilacji ma install
cel, w szczególności Makefile (tam, gdzie jest to zalecane na przykład przez GNU ) lub CMake . Ten cel kopiuje pliki środowiska wykonawczego (pliki wykonywalne, biblioteki, ...) w systemie operacyjnym (na przykład w C:\Program Files\
systemie Windows).
Jest to naprawdę hackerskie, ponieważ dla mnie nie jest obowiązkiem kompilacji systemu instalowanie programów (co w rzeczywistości jest odpowiedzialnością systemu operacyjnego / menedżera pakietów). Oznacza to również, że system kompilacji lub skrypt kompilacji musi znać organizację zainstalowanych programów, ze zmiennymi środowiskowymi, zmiennymi rejestru, dowiązaniami symbolicznymi, uprawnieniami itp.
W najlepszym wypadku systemy kompilacji powinny mieć release
cel, który wyśle program instalacyjny (na przykład .deb
lub .msi
), a następnie uprzejmie poprosi system operacyjny o zainstalowanie tego programu. Umożliwiłoby to również użytkownikowi odinstalowanie bez konieczności pisania make uninstall
.
Więc moje pytanie: dlaczego system kompilacji zwykle zaleca posiadanie install
celu?
źródło
make install
zwykle instaluje się w/usr/local
(a nawet/opt
) katalogach nieobsługiwanych przez „podstawowy system zarządzania pakietami / systemami operacyjnymi”. Nie mam pojęcia, czy system Windows ma podobną konwencję.make install
że nie ma to sensu, gdy mówimy o kompilacji krzyżowejDESTDIR
.Odpowiedzi:
Wiele skryptów kompilacji lub plików Makefiles ma cel instalacji, ponieważ zostały one utworzone przed istnieniem menedżerów pakietów i ponieważ nawet dziś wiele systemów nie ma menedżerów pakietów. Ponadto istnieją systemy, w których
make install
faktycznie jest preferowanym sposobem zarządzania pakietami.źródło
make install
jest preferowany. Poza tym miałem na myśli menedżera programów, kiedy powiedziałem, że makefile powinny tworzyć instalowalne pakiety. Myślę, że prawie wszystkie systemy operacyjne posiadają sposób zarządzania zainstalowanymi programami? Na przykład system Windows nie ma menedżera pakietów (poza sklepem), ale nadal ma sposób zarządzania zainstalowanymi programami (za pomocą.msi
pakietów na przykład)make install
.checkinstall
zmake install
dwóch powodów: „Możesz łatwo usunąć pakiet jednym krokiem”. i „Możesz zainstalować wynikowy pakiet na wielu komputerach”. - ponieważ checkinstall buduje .deb i instaluje go, używa menedżera pakietów ...make install
checkinstall
wywołanie faktycznie używamake install
i monitoruje jego działania w celu budowania pakietów.A
makefile
może nie miećinstall
celu, a co ważniejsze, możesz mieć programy, które nawet nie powinny być instalowalne (np. Ponieważ powinny działać z katalogu kompilacji lub ponieważ mogą być zainstalowane w dowolnym miejscu).install
Cel jest tylko konwencja dla zwykłychmakefile
-s.Jednak wiele programów wymaga uruchamiania zasobów zewnętrznych (na przykład: czcionek, baz danych, plików konfiguracyjnych itp.). Ich pliki wykonywalne często stawiają hipotezę na temat tych zasobów. Na przykład,
bash
powłoka będzie na ogół przeczytać jakiś plik inicjalizacji od/etc/bash.bashrc
etc .... Zasoby te są na ogół w systemie plików (patrz hier (7) do konwencji o hierarchii plików), a domyślna ścieżka pliku jest wbudowany w plik wykonywalny.Spróbuj użyć ciągów (1) w większości plików wykonywalnych systemu. Dowiesz się, jakie ścieżki do plików są mu znane.
BTW, dla wielu używających programów GNU
autoconf
można uruchomićmake install DESTDIR=/tmp/destdir/
bez rootowania. Następnie/tmp/destdir/
jest wypełniany plikami, które powinny być później spakowane.FWIW, uważam, że mojego programu bismon (licencjonowanego na GPLv3 +) (opisanego w moim raporcie bismon-chariot-doc.pdf ) nie można „zainstalować”; Nie jestem pewien, czy będę w stanie to udowodnić, i nie wyobrażam sobie, jak sprawić, by ten program był instalowalny.
źródło
/opt
Lub w$HOME
. Jedynym sposobem uniknięcia różnych prefiksów jest użycie kontenerów, ale jest to oczywiście rozwiązanie specyficzne dla systemu Linux../configure --prefix="/opt/foo" && make && DESTDIR=/tmp/foo make install
i móc przenieść pakiet/opt/foo
bez żadnych problemów.Przychodzi mi na myśl kilka powodów.
$HOME
katalogu. Nie wszyscy menedżerowie pakietów obsługują to.źródło
Jednym z powodów, o których nie wspomniano, jest to, że wiele razy nie używasz bieżącej wersji oprogramowania lub używasz zmodyfikowanej wersji oprogramowania. Próba stworzenia niestandardowego pakietu to nie tylko więcej pracy, ale może powodować konflikt z aktualnie tworzonymi i dystrybuowanymi pakietami. W otwartym kodzie źródłowym dzieje się to często, zwłaszcza jeśli w przyszłych wersjach, których używasz, wprowadzane są przełomowe zmiany.
Załóżmy, że korzystasz z projektu open source FOO, który jest obecnie w wersji 2.0.1 i używasz wersji 1.3.0. Nie chcesz używać niczego powyżej, ponieważ wersja 2.0.0 jest niezgodna z tym, co obecnie robisz, ale istnieje jedna poprawka błędu w wersji 2.0.1, której desperacko potrzebujesz. Dzięki tej
make install
opcji możesz zainstalować zmodyfikowane oprogramowanie 1.3.0 bez martwienia się o utworzenie pakietu i zainstalowanie go w systemie.źródło
Dystrybucje Linuksa zasadniczo oddzielają obsługę programu od obsługi pakietu. System kompilacji, który integruje generowanie pakietów, zmusiłby opiekunów programów do przeprowadzania również konserwacji pakietów.
To zwykle zły pomysł. Dystrybucje mają wiele infrastruktury do weryfikacji wewnętrznej spójności, zapewniają pliki binarne dla wielu platform docelowych, wykonują małe zmiany w celu lepszej integracji z resztą systemu i zapewniają spójne środowisko dla użytkowników zgłaszających błędy.
Aby wygenerować pakiety bezpośrednio z systemu kompilacji, musisz zintegrować lub ominąć całą tę infrastrukturę. Jego integracja byłaby bardzo pracochłonna dla wątpliwych korzyści, a jej ominięcie dałoby gorsze wrażenia dla użytkownika.
Jest to jeden z najbardziej typowych problemów w systemach wielopartyjnych. Jeśli masz wiele złożonych systemów, musi istnieć jasna hierarchia, który system jest odpowiedzialny za koordynację wszystkich innych.
W przypadku zarządzania instalacją oprogramowania menedżerem pakietów jest ten komponent, który uruchomi system kompilacji pakietu, a następnie przejdzie przez wygodny interfejs („pliki w katalogu po kroku instalacji”), wygeneruje pakiet i przygotuje w celu przesłania do repozytorium.
Menedżer pakietów stoi tutaj pośrodku między systemem kompilacji a repozytorium i jest w najlepszej pozycji, aby dobrze zintegrować się z obydwoma.
Być może zauważyłeś, że jest tylko kilka pakietów JavaScript dostępnych za pośrednictwem
npm
również dostępnych poprzezapt
- to głównie dlatego, że ludzie JavaScript zdecydowali, żenpm
i powiązane z nim repozytorium będzie na szczycie ich łańcucha pokarmowego, co sprawiło, że prawie niemożliwe było wysyłaj te pakiety jako pakiety Debiana.Z moim kapeluszem dewelopera Debiana: jeśli wypuszczasz oprogramowanie typu open source, zostaw opakowanie opiekunom dystrybucji. Oszczędza to zarówno Tobie, jak i nam dużo pracy.
źródło
Cóż, twórcy aplikacji wiedzą, gdzie powinien iść każdy plik. Mogą zostawić to w dokumentacji i poprosić opiekunów pakietu o przeczytanie tego i zbudowanie skryptu dla każdego pakietu. Być może opiekunowie pakietów źle interpretują dokumentację i będą musieli debugować skrypt, dopóki nie zadziała. To jest nieefektywne. Twórcy aplikacji lepiej jest napisać skrypt, aby poprawnie zainstalować napisaną przez siebie aplikację.
Mógłby napisać skrypt instalacyjny o dowolnej nazwie lub może włączyć go do procedury innego skryptu. Jednak mając standardowe polecenie instalacji
make install
(konwencja, która poprzedza menedżerów pakietów), tworzenie pakietów jest naprawdę łatwe. Jeśli spojrzysz na szablon PKGBUILD do tworzenia pakietów Archlinux , możesz zobaczyć, że funkcja, która faktycznie pakuje, po prostu wykonujemake DESTDIR="$pkgdir/" install
. Prawdopodobnie działa to dla większości pakietów i prawdopodobnie więcej z niewielką modyfikacją. Dzięki temu, żemake
(i narzędzia automatyczne) są standardowe, pakowanie jest naprawdę bardzo łatwe.źródło