2009.06_Automatyzacja instalacji ze źródeł_[Rozwiazania].pdf

Rozwiązania

Automatyzacja instalacji ze źródeł

instalacji ze źródeł

Sylwester Zdanowski

Oprogramowanie przeznaczone dla systemu Linux może być instalowane na trzy podstawowe sposoby:

za pomocą pakietów dostosowanych do konkretnej dystrybucji, poprzez kreatory instalacji jak ma

to miejsce z SeaMonkey, lub przez kompilacje. Ostatnia metoda, choć bywa kłopotliwa, jest godna

największej uwagi dla użytkownika końcowego. Dla osób chcących tworzyć oprogramowanie dla

systemu Linux jest ona wręcz niezbędna.

wymaga wykonania skryptu koniguracyjne-

go oraz przeprowadzenia kompilacji. Pierwszy

z wymienionych kroków polega na wywołaniu

skryptu conigure. Do utworzenia tego skryptu służy narzędzie

Autoconf, jest ono potrzebne jedynie przy tworzeniu skryptu.

Głównym celem wspomnianego narzędzia i skryptu konigura-

cyjnego nie jest jednak ułatwienie pracy programistom. Pozwa-

la ono przede wszystkim na zachowanie możliwie największej

kompatybilności procesu instalacji ze wszystkimi możliwymi

systemami operacyjnymi. Przekłada się to na względną prosto-

tę instalacji dla użytkownika końcowego.

Zasadniczą zaletą instalacji ze źródeł na etapie konigura-

cji jest możliwość dostosowania instalowanych funkcji opro-

gramowania do własnych potrzeb. Możliwość usunięcia zbęd-

nych elementów jest szczególnie istotna w przypadku progra-

mów narażonych na ataki. Z tego właśnie powodu dobrą prak-

tyką jest kompilowanie, nie zaś instalowanie z pakietów wsze-

lakich usług. Lista takiego oprogramowania jest niebywale

długa, wymienić można chociażby Apache2 czy php.

W procesie koniguracji wychwycone zostaną również

wszelakiego rodzaju braki w systemie. Jeżeli nie jest zainstalowa-

ne jakiekolwiek wymagane przez program oprogramowanie czy

biblioteka, proces koniguracji zakończy się niepowodzeniem.

Konieczne jest wówczas uzupełnienie braków w systemie.

Kolejnym etapem jest kompilacja wywoływana przez

polecenie make . Etap ten wykonywany jest przez zainstalo-

wany kompilator, można go podzielić na trzy etapy. O ile w

omawianym temacie szczegółowy przebieg kompilacji nie

jest interesujący, ważne są lagi kompilatora. Za ich pomocą

możliwa jest optymalizacja kodu pod kątem architektury sys-

temu oraz szybkości wykonania. Należy jednak pamiętać, iż

korzystanie ze wszystkich dostępnych lag może spowodo-

wać więcej kłopotów niż przynieść korzyści.

Ostatnim etapem jest sama instalacja, już skompilowane-

go programu. Poprzez polecenie make install następuje sko-

Czego się dowiesz:

• Z jakich etapów składa się proces tworzenia me-

chanizmu instalacji oprogramowania ze źródeł;

• Jaki sens ma taki mechanizm;

• Na czym polega każdy z etapów procesu.

czerwiec 2009

Automatyzacja

O d strony użytkownika końcowego kompilacja

Rozwiązania

Automatyzacja instalacji ze źródeł

piowanie plików we właściwe w systemie miej-

sca. Miejsca te można określić wykonując krok

pierwszy, czyli konigurację. Jeżeli nie został po-

dany właściwy parametr, wykorzystane zostaną

domyślnie zdeiniowane ścieżki.

Dalsza część artykułu przedstawi ilary

standardu tworzenia źródeł przeznaczonych do

instalacji oprogramowania. Informacje te będą

pomocą dla osób mających problem z wykona-

niem kompilacji oprogramowania na własnym

komputerze oraz mapą drogową dla nowych

twórców takiego oprogramowania.

• informacje na temat praw własności, auto-

ra i licencji. Patrząc na przykład programu

ekg należy pamiętać o $Id zawierającym

informacje o czasie ostatniej zmiany pliku;

• wspomniane już makro AC_INIT. W przy-

padku ekg2 zawiera jedynie nazwę pro-

jektu, może również informować o wersji

oraz drodze raportowania problemów;

• kolejne makro AC_PREREQ określa po-

trzebną wersję programu Autoconf.

kiwana jest jedna z zadeklarowanych alternatyw.

Osobne makra przeznaczone są do sprawdzania

obecności wymaganych bibliotek, a nawet działa-

nia funkcji C. Funkcje tego języka w starych sys-

temach zachowują się w sposób znacznie odbie-

gający od obecnie zdeiniowanego. Przykładem

może być funkcja exit , która zwracała wartość

int , nie zaś void jak ma to miejsce obecnie.

W przypadku braku makra przeznaczone-

go do testowania konkretnej funkcjonalności

dostępne są testy o większej elastyczności. Po-

zwalają one na sprawdzenie obecności w syste-

mie dowolnego pliku czy funkcji. Ostateczno-

ścią jest pisanie własnych testów.

Po zakończeniu wszystkich testów plik musi

zawierać ostatni element: makro AC_OUTPUT.

Przy czym o ile nazwa makra może być bardziej

sugestywna, jest ono obecnie uznane za przesta-

rzałe i zastępowane makrem AC_CONFIG.

Aby zagmatwać całość jeszcze bardziej,

należy dodać, iż jak Autoconf służy tworzeniu

pliku makeile , tak tworzeniu pliku conigure.ac

ma pomagać Autoscan. Narzędzie to przejrzy

wskazany katalog w poszukiwaniu plików źró-

dłowych, po czym utworzy plik conigure.scan .

Teoretycznie jego nazwę można zmienić na

conigure.ac . Jednak taki automatycznie wyge-

nerowany plik nie będzie idealny. Wykorzystu-

jąc go za podstawę należy sprawdzić kolejność

makr oraz uzupełnić braki.

Właściwe ciało pliku składa się z makr, które ma-

ją zostać wykonane przez skrypt koniguracyjny.

Czynności te przede wszystkim obejmują spraw-

dzenie dostępnych elementów systemu jak pliki

nagłówkowe i biblioteki. Istotnym dla następne-

go kroku jest ustawienie w tej części pliku zmien-

nej środowiskowej CFLAGS . Określa ona lagi wy-

korzystane przy kompilacji programu. Przeważa-

jącą część pliku w przypadku ekg2 tworzą makra

obsługujące argumenty przekazane przy wywo-

łaniu koniguracji, oraz sprawdzające obecność

wymaganych elementów systemu.

Dostępne makra przeznaczone są do testo-

wania elementów systemu, które mogą być wy-

magane przez instalowane oprogramowanie.

W przypadku, gdy brakuje gotowego makra

do sprawdzenia wymaganej funkcjonalności,

możliwe jest stworzenie własnych makr.

Gotowe rozwiązania obejmują testy wie-

lu aspektów systemu. Przede wszystkim moż-

liwe jest sprawdzanie dostępnych w systemie

plików nagłówkowych. Ze względu na różnice

między systemami, na których wykorzystywa-

ne może być oprogramowanie, test ten powi-

nien uwzględniać alternatywne nagłówki.

Kolejne testy dotyczą dostępnych progra-

mów oraz ich zamienników jak AC_PROG_

AWK. Makro sprawdza dostępność programu

gawk. Jeżeli nie zostanie on znaleziony, wyszu-

Autoconf

Pierwszym krokiem do stworzenia względnie

prostej możliwości instalowania programu ze

źródeł jest napisanie pliku autoconf.ac . Plik ten

jest wymagany przez narzędzie Autoconf; na

jego podstawie tworzony jest wykorzystywany

przez użytkownika końcowego plik conigure .

Może się nasunąć pytanie, dlaczego wyko-

rzystywać dodatkowe narzędzie zamiast napisać

skrypt powłoki wykonujący dokładnie to samo

zadanie. Bardzo dobrym dowodem, iż nie jest to

najlepszy pomysł, jest źródło programu ekg2. Po

jego ściągnięciu i rozpakowaniu można spraw-

dzić, iż plik conigure.ac ma ponad 700 linii, zaś

conigure ponad 33 tysiące linii. Chyba nikogo

nie trzeba przekonywać, który plik lepiej napi-

sać. Ponadto narzędzie to gwarantuje możliwie

wysoką kompatybilność koniguracji.

Język Autoconf znacznie różni się od C czy

C++. We wspomnianych językach, dających dużą

kontrolę nad przebiegiem programu, składnia in-

strukcji i danych jest wyraźnie różna. W przypad-

ku Autoconf mamy do czynienia z wykorzysta-

niem makr, przy których wszystko jest traktowa-

ne w taki sam sposób. Do rozróżnienia elementów

składni wykorzystywane są nawiasy kwadratowe.

Budowa conigure

Dysponując plikiem conigure.ac można stwo-

rzyć właściwy plik conigure . Wystarczy w tym

celu wywołać polecenie autoconf z właściwy-

mi parametrami. Aby sprawy nie były nazbyt

proste, możliwe jest stworzenie reguł pozwa-

lających na automatyczną aktualizację pliku

koniguracyjnego w przypadku jakichkolwiek

zmian, które mają wpływ na jego zawartość.

Budowa conigure.ac

Plik conigure.ac można podzielić na trzy części:

początek, właściwe ciało pliku i zakończenie.

Jedynymi wymaganymi elementami pliku są

makra: AC_INIT oraz AC_OUTPUT. Pozostała

część pliku nie ma nawet zdeiniowanej kolej-

ności, o ile bezpośrednio odnoszące się do siebie

czynności są wykonywane we właściwej kolej-

ności. Pomimo tej dużej dowolności można usta-

lić pewną sugerowaną strukturę pliku. Początek

pliku powinien zawierać następujące elementy:

Tabela 1. Parametry kompilacji

parametr Znaczenie

-march

Pozwala na określenie procesora, np. pentium4

-O

Ustawia wiele lag zależnie od wybranego poziomu kompilacji. Dostępne są poziomy od

O0 do O3. Zalecany jest poziom O2

-pipe

Zmienia sposób pracy kompilatora nie wpływając na efekt końcowy. Poprzez używanie po-

toków przyspiesza proces

Czym jest Autoconf

Listing 1. Fragment pliku Makeile

1: CFLAGS = -g -O2 -Wall -c

2: SRCS = program.c plik.c

3: all: main

4: main.o: main.c plik.h

5: gcc $(CFLAGS) main.o

Problemem, który ma rozwiązywać Autoconf jest bałagan na świecie.

Przede wszystkim służy łatwej kompilacji programu w różnych środowiskach, niektórych

bardzo wrogich. Autoconf sam nosi brzemię tego wyzwania, musi działać na wszystkich

tych systemach. Dlatego conigure może wykorzystywać tylko funkcje będące wspólnym

mianownikiem wszystkich tych systemów.

Tłumaczenie ze strony: http://www.gnu.org/software/autoconf/manual/autoconf.txt

www.lpmagazine.org

Rozwiązania

Automatyzacja instalacji ze źródeł

W ostatecznym rozrachunku plik ten zawiera

makra użyte w pliku conigure.ac w formie skryp-

tów powłoki. Na przykładzie ekg2 wyraźnie wi-

dać, iż jest to skrypt powłoki sh . Widać również

cel użycia Autoconf. Skrypt zawiera liczne frag-

menty kontrolujące środowisko i zapewniające

kompatybilność. Od strony użytkownika końco-

wego istotne są obsługiwane przez niego parame-

try. Z posiadanych plików dużo łatwiej odnaleźć

te parametry w pliku conigure.ac od linii 123. Jak

już było wspomniane, parametry te mają zasadni-

cze znaczenie dla elastyczności tej metody insta-

lacji. Po podaniu przez użytkownika wybranych

przez niego parametrów z pliku conigure tworzo-

ny jest plik Makeile . Parametry te w większości

obejmują specyiczne dla każdego programu funk-

cje, których obsługę można włączyć lub wyłączyć.

Tworzony jest również jeszcze jeden istotny plik,

mianowicie conig.status , pozwalający na odtwo-

rzenie koniguracji programu w przyszłości.

W zależności od przyjętej metody przekazy-

wania informacji możliwe jest utworzenie pliku

zawierającego wszystkie wyniki badania systemu.

Makeile . Plik ten będący zasadniczo końco-

wym etapem przygotowania do instalacji moż-

na również napisać własnoręcznie ze wszystki-

mi wadami i zaletami takiego postępowania.

nych jak największym poziomem optymaliza-

cji instalowanego kodu godny polecenia jest sys-

tem Gentoo. W jego przypadku kompilacja źró-

deł i wynikająca z tego optymalizacja jest podsta-

wą idei istnienia. Po zakończeniu kompilacji po-

zostaje jedynie wykonanie instalacji. Należy pa-

miętać, aby z katalogu źródłowego zachować plik

conig.status . Pozwoli on odtworzyć konigurację

w przypadku usunięcia pozostałych plików.

Ostatnim elementem instalacji oprogramo-

wania ze źródeł jest kompatybilność kodu, któ-

ry zostaje skompilowany. Programiści oprogra-

mowania wykorzystywanego na różnych syste-

mach operacyjnych z różnych okresów muszą

uważać na różnice między systemami. Przy-

kładem jest różne zachowanie się programów

przy powstaniu liczby całkowitej o zbyt dużym

rozmiarze. W niektórych przypadkach zamiast

do przekręcenia się licznika, doprowadzi to do

przepełnienia bufora. Błąd taki można wyko-

rzystać do ataku na bezpieczeństwo systemu.

Pisanie Makeile

Makeile zawiera przede wszystkim deinicje

zmiennych oraz zależności, jakie sprawiają, iż da-

ny plik musi zostać powtórnie skompilowany.

Na Listingu 1 widoczny jest fragment pro-

stego pliku Makeile . Obrazuje on funkcje pli-

ku. Linie 1 i 2 zawierają zmienne, linia 3 głów-

ną regułę, która zostanie wykonana przez ma-

ke, a linie 4 i 5 określają zależność między

dwoma plikami oraz czynność do wykonania.

Wystarczy jednak spojrzeć na przykłado-

wy plik Makeile wykorzystywany przez pro-

gram ekg2, aby zobaczyć znacznie bardziej zło-

żone możliwości tegoż pliku. Pisanie go własno-

ręcznie może być użyteczne jedynie w przypad-

ku bardzo małych zadań na własny użytek. Jedy-

nie zastosowanie kreatorów daje gwarancje kom-

patybilności.

Podsumowanie

Niewątpliwie kompilacja oprogramowania nie-

sie ze sobą wiele zalet. Drugą stroną tego meda-

lu jest większy poziom komplikacji niż w przy-

padku instalacji programów z wykorzystaniem

pakietów. Sama długość trwania kompilacja du-

żych elementów środowiska jak KDE może być

zniechęcająca, pomimo długofalowych korzy-

ści. Wykorzystanie tej metody instalacji jest za-

leżne od potrzeb oraz własnych preferencji. Jest

to jedna z cech systemu Linux, iż zawsze istnie-

je alternatywna droga postępowania.

Programiści chcący wykorzystać przedsta-

wione narzędzia do rozpowszechniania swoich

programów powinni odwołać się do dalszych

źródeł. Pełna dokumentacja przedstawionych

narzędzi i nie tylko jest łatwa do znalezienia

na stronach projektu GNU. Można tam znaleźć

zarówno historie, teorie, jak i opis dostępnych

makr. Właściwe adresy znajdują się w ramce.

Z kolei dla osób jedynie instalujących opro-

gramowanie ze źródeł niepotrzebna powinna być

głębsza wiedza niż przedstawiona w artykule.

Przy dobrze napisanych programach i odrobinie

szczęścia instalacja powinna się zamykać w kil-

ku prostych poleceniach.

Makeile

Do wykorzystania skryptu conigure potrzebny

jest jeszcze plik Makeile.in . Razem z wcześniej

utworzonym plikiem conigure pozwoli on na

utworzenie końcowych reguł kompilacji progra-

mu na konkretnej maszynie. Droga do utworze-

nia wymaganego pliku jest podobna jak w przy-

padku Autoconf. Punkt wyjściowy stanowi plik

Makeile.am . Plik o tej nazwie znajduje się w

każdym katalogu projektu zawierającym źródła

do kompilacji. Pliki te mogą zawierać:

Make kompilacje

Końcowy użytkownik programu powinien być

w stanie w możliwie bezbolesny sposób przejść

przez instalację. W przypadku narzędzia make

interesujące są jedynie dostępne reguły do wyko-

nania oraz parametry optymalizacji. Zazwyczaj

dostępne są reguły kompilacji, instalacji, czysz-

czenia i usunięcia programu. Dużo bardziej warte

uwagi są parametry, jakie przed kompilacją moż-

na przekazać kompilatorowi. W przypadku języ-

ka C zmienną środowiskową odpowiedzialną za

parametry kompilacji jest CFLAGS , dla C++ jest to

CXXFLAGS . Zmienne te mogą być ustawione po-

przez konigurację programu, jednak możliwa

jest ich optymalizacja przez użytkownika. Cza-

sowo ustawić je można po przez eksportowanie

ich jako zmiennych środowiskowych.

Należy zacząć od zrozumienia, iż nadmierna

optymalizacja może spowodować więcej proble-

mów niż dać korzyści. Mając powyższe stwier-

dzenie w pamięci można spokojnie stosować kil-

ka podstawowych lag. Dla osób zainteresowa-

• lagi przekazywane kompilatorowi;

• listę programów do kompilacji;

• listę plików;

• lagi przeznaczone do linkowania.

Najważniejszym elementem jest informacja, które

podkatalogi zawierają źródła. Wykorzystując tę in-

formację Automake w sposób rekurencyjny prze-

chodzi przez wszystkie wymienione katalogi.

Wynikiem końcowym wykonania skryptu

conigure z plikiem Makeile.in jest powstanie

W Sieci

Czym jest Automake

• http://www.gnu.org/software/autoconf/

– strona główna projektu autoconf;

• http://www.gnu.org/software/automake/

manual/html_node/Creating-

amhello.html#Creating-amhello – opis

niewielkiego przykładu;

• http://www.gnu.org/software/

automake/manual/html_node/Macro-

Index.html#Macro-Index – index makr.

O autorze

Automake pozwala na określenie wyma-

gań kompilacji w pliku Makeile.am . Jest on

dużo prostszy i dysponuje większymi moż-

liwościami niż czysty makeile . Następnie

generuje wielo platformowy Makeile.in ,

wykorzystywany przez Autoconf.

Tłumaczenie ze strony: http://www.gnu.org/

software/autoconf/manual/autoconf.txt

Absolwent technikum policealnego na kierun-

ku informatyki w Szczecinie. Obecnie student

2 roku Europeistyki na Uniwersytecie Szcze-

cińskim. Od ponad roku pracownik irmy

świadczącej usługi internetowe w Gryinie.

Kontakt z autorem:

sylwesterzdanowski@o2.pl

czerwiec 2009

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: