Mylić o skrypcie konfiguracyjnym i Makefile.in

Question

Obecnie uczę się korzystać z narzędzia toolchain autoconf/automake. Wydaje mi się, że rozumiem tutaj przepływ pracy - w zasadzie masz skrypt configure.ac, który generuje plik wykonywalny configure. Wygenerowany skrypt configure jest następnie wykonywany przez użytkownika końcowego w celu wygenerowania Makefile s, aby można było zbudować/zainstalować program.

Więc instalacja dla typowego użytkownika końcowego jest zasadniczo:

./configure 
make 
make install 
make clean 

Dobra, teraz tu, gdzie jestem zdezorientowany:

Jako deweloper, zauważyłem, że auto generowane skonfigurować skrypt czasami nie będzie działać i będzie Błąd:

config.status: error: cannot find input file: `somedir/Makefile.in' 

To mnie niepokoi, bo myślałem, że skrypt konfiguracyjny ma generować the Makefile.in. Więc szukając odpowiedzi, odkryłem, że można to naprawić za pomocą skryptu autogen.sh, który zasadniczo "resetuje" stan środowiska autoconf. Typowy skrypt autogen.sh może wyglądać następująco:

aclocal \ 
&& automake --add-missing \ 
&& autoconf 

Okay w porządku. Ale jako użytkownik końcowy, który pobierał niezliczone ilości archiwów przez całe moje życie, nigdy nie miałemużywać skryptu . Wszystko, co zrobiłem, to rozpakowanie tarballa i wykonanie zwykłej procedury configure/make/make install/make clean.

Ale jako deweloper, kto jest teraz użyciuautoconf wydaje się, że configure faktycznie nie działać, jeśli nie uruchomić autogen.sh pierwszy. Dlatego uważam, że jest to bardzo mylące, ponieważ uważałem, że użytkownik końcowy nie powinien uruchamiać autogen.sh.

Po pierwsze, muszę najpierw uruchomić autogen.sh - aby skrypt konfiguracyjny mógł znaleźć Makefile.in? Dlaczego skrypt konfiguracyjny po prostu go nie generuje?

Answer 1

Aby naprawdę zrozumieć narzędzia autotools, trzeba pamiętać, skąd pochodzą: pochodzą ze świata open source, w którym znajdują się (a) programiści pracujący z repozytorium kodu źródłowego (CVS, Git itp.)) i utworzenie pliku tar lub podobnego zawierającego kod źródłowy i umieszczenie tego pliku tar na stronie pobierania, oraz (b) użytkownicy końcowi, którzy otrzymują plik tar kodu źródłowego, kompilowanie tego kodu źródłowego w systemie i użycie wynikowego pliku binarnego . Oczywiście ludzie w grupie (a) również kompilują kod i używają wynikowego pliku binarnego, ale ludzie w grupie (b) nie mają lub nie potrzebują często wszystkich narzędzi do rozwoju, których potrzebują ludzie w grupie (a).

więc użycie narzędzi jest ukierunkowana tego rozłamu, gdzie ludzie w grupie (b) nie mają dostępu do autoconf, automake, itd

Podczas korzystania autoconfa, ludzie generalnie sprawdza w configure.ac plik (wejście do autoconf) do kontroli kodu źródłowego, ale nie sprawdzaj wyjścia autoconf, skryptu configure (niektóre projekty sprawdzają oczywiście w skrypcie configure: to zależy od ciebie).

Podczas korzystania z automake, ludzie zazwyczaj sprawdzają plik Makefile.am (wejście do automake), ale nie sprawdzają wyjścia automake: Makefile.in.

Skrypt zasadniczo analizuje Twój system pod kątem różnych elementów opcjonalnych, które pakiet może, ale nie musi, gdzie można je znaleźć, itp. Po znalezieniu tej informacji można jej użyć do konwersji różnych plików XXX.in (zazwyczaj , ale nie wyłącznie, Makefile.in) w plikach XXX (na przykład Makefile).

Więc kroki generalnie iść tak: napisać configure.ac i Makefile.am i sprawdzić je w celu budowania projektu z kontroli kodu źródłowego kasie, uruchom autoconfa generowania configure z configure.ac.. Uruchom program automake, aby wygenerować Makefile.in z Makefile.am. Uruchom configure, aby wygenerować Makefile z Makefile.in. Uruchom make, aby zbudować produkt.

Gdy chcesz udostępnić kod źródłowy (jeśli rozwój produktu open source, która sprawia, że ​​wersje kodu źródłowego) uruchomieniu autoconf i automake, a następnie zbierać kod źródłowy z configure i Makefile.in plików, tak, że ludzie budowanie wersji kodu źródłowego wymaga tylko make i kompilatora i nie potrzebuje żadnych autotoolów.

Ponieważ kolejność uruchamiania autoconf i automake (i libtool jeśli go używasz) może być trudna, istnieją skrypty takie jak autogen.sh i autoreconf, itp., Które są sprawdzane w kontrolce źródłowej do wykorzystania przez deweloperów budujących z kontroli źródła , ale nie są one potrzebne/używane przez ludzi budujących z pliku tar o wydaniu kodu źródłowego itp.

Autoconf i automake są często używane razem, ale możesz użyć autoconf bez automake, jeśli chcesz napisać własny Makefile.in.