To następny krok. Gdy już ma się te źródła rozpakowane a łatki ponakładane
można przejść do właściwej kompilacji. Teraz zwykle trzeba uruchomić skrypt
./configure z odpowiednimi parametrami, a potem wywołać ,,make''. Można
tutaj postąpić ,,normalnie'' i napisać np. taką sekcję:
%build
./configure --prefix=/usr --mandir=/usr/share/man --enable-nls
make
Można też pójść o krok dalej i zacząć używać zmiennych ze środowiska RPM, co
pozwoli potem łatwiej dopasowywać skrypty itp. bzdury ;)
%build
./configure --prefix=%{_prefix} --mandir=%{_mandir} --enable-nls
make
Można też pójść na całość i napisać tak:
%build
%configure --enable-nls
make
Tutaj użyłem zamiast ,,gołego'' wywołania ./configure specjalnego, rpm-owego
makra ,,%configure''. Makro to uruchamia skrypt ./configure, ale
przy okazji przekazuje mu długą listę opcji w stylu ,,--prefix=%{_prefix}
--bindir=%{_bindir} --docdir=%{_docdir}'' itd.
Za jednym zamachem makro to definiuje też zmienne CFLAGS, CXXFLAGS oraz
FFLAGS. Najpierw próbuje je pobrać ze środowiska, a jeśli to się nie
powiedzie (bo zmienne nie były ustawione w shellu z którego uruchomiono
rpmbuild), to ustawi brakujące zmienne na wartość %{optflags}
- a %{optflags} to domyślne (można w sumie powiedzieć - awaryjne) flagi
kompilacji w środowisku RPM.
%{optflags} można oczywiście ustawić sobie np. w pliku ~/.rpmrc.
Można się tutaj spierać, czy wywołanie %configure należy umieścić
w sekcji %build, czy też może bardziej pasowałoby to do sekcji %prep. Ale to
nie jest tutaj ważne.
A teraz kolejne odejście od głównego tematu: skrypt ./configure. Czasem
zachodzi potrzeba zregenerowania go - bo albo mamy zbyt nowy pakiet
autoconf/automake (a skrypt ./configure był stworzony jakimiś archaicznymi
wersjami tych programów), albo po prostu musieliśmy powprowadzać jakieś
poprawki do procesu ./configure i trzeba jeszcze raz pozwolić automatom to
,,przemielić''. Albo chcemy skompilować kod z CVS, który często nie zawiera
skryptów ./configure a jedynie ich wersje ,,źródłowe''. Regeneracja
wszystkich skryptów automatu ./configure nie jest zwykle potrzebna, ale
różnie to bywa. I zwykle proces ten sprowadza się do łańcucha poleceń,
czegoś w rodzaju:
przy czym zestaw poleceń i ich opcje mogą się różnić zależnie od sytuacji.
Sam pakiet autoconf oferuje osobny program, który powinien być zwykle
w stanie wykryć co też wymaga aktualizacji i samodzielnie zadecydować co
i z jakimi opcjami uruchomić. Program ten (a właściwie to skrypt shellowy)
nazywa się ,,autoreconf''. I często zamiast litanii poleceń wystarczy
wklepać ,,autoreconf''. RPM ma jednak własną wersję podobnego narzędzia
- makro %GNUconfigure. Odwala ono w przybliżeniu tę samą robotę co
,,autoreconf''. Obeznani z tematem będą pewnie i tak woleli samodzielnie
uruchamiać poszczególne ,,klocki'' w rodzaju ,,aclocal'' czy ''autoheader'',
mniej zaawansowani mogą spróbować skorzystać z automagicznych mechanizmów
,,autoreconf'' czy ,,%GNUconfigure''. Automagia nie zawsze zadziała, ale
jest z pewnością mniej wymaga od użytkownika. Dlatego o niej wspominam, no
i udało mi się dzięki temu wpleść trochę informacji o %GNUconfigure
;)
I tutaj znowu nie bardzo wiadomo, czy regeneracja ./configure powinna
znajdować się w sekcji %build, czy też może jednak
w %prep. Ja osobiście bym się skłaniał ku umieszczeniu tego jeszcze
w sekcji %prep, bo to należy według mnie jeszcze do fazy
przygotowywania źródeł, podobnie jak patchowanie. Ale to nie gra większej
roli, niezależnie od wyboru efekt będzie ten sam :)
A gdy już mamy te źródła skonfigurowane, wystarczy uruchomić ,,make''. Więc
przykładowa prosta sekcja %build mogłaby w rezultacie wyglądać tak: