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 należy 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.

Po raz kolejny odejdę od głównego tematu i zajmę się skryptem ./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:

libtoolize --force
aclocal
autoheader
automake -af
autoconf

...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 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:

%build
%configure --without-alsa
make