Hlavní navigace

Kompilujeme ze zdrojového kódu - tajemný skript configure

26. 8. 2002
Doba čtení: 9 minut

Sdílet

Často čteme o „magické trojici ./configure ; make ; make install“. Dnes se dozvíme více o možnostech tohoto skriptu a jeho volbách. Povíme si také o standardech GNU Coding Standards a FHS, tedy doporučeních, kam instalovat programy.

Jak jsme si již řekli dříve, základním úkolem configure je otestovat systém, správně nastavit konfiguraci a vytvořit soubory Makefile. Jeho chování je možné ovlivňovat pomocí proměnných a argumentů na příkazové řadce. Jde především o to, které volitelné možnosti aktivovat, ale také o instalační cesty.

Konvence pro configure

Každý configure skript by měl reagovat na –help a vypsat všechny konfigurační volby (ne vždy je tomu tak).

V následující části budeme rozebírat jeho obecné volby, týkající se cest, knihoven a keše. Kromě nich může mít každý program další, individuální volby.

Ty mívají většinou jednu ze dvou základních forem: přepínače a předávané hodnoty.

Přepínače

Typický přepínač pro configure má tvar –enable-vlastnost. Bývá k dispozici i opačný přepínač, a to ve formě –disable-vlastnost. V nápovědě by mělo být uvedeno implicitní nastavení.

Předávané hodnoty

Tyto volby se používají, je-li třeba předat skriptu nějaké hodnoty. Typicky se jedná o cesty k nějakým balíčkům v systému, vícestavové přepínače, nebo seznam požadovaných vlastností či komponent (oddělených čárkou). Hodnota se typicky předává pomocí –with-vlastnost=hod­nota. Někdy bývá možnost použít jej bez argumentů – –with-vlastnost(použije se implicitní hodnota) anebo jako negaci – –without-vlastnost.

GNU Coding Standards

GNU zavedlo své kódové standardy. Ty mimo jiné podle povahy dat definují adresáře, do kterých mají data přijít. Pod definicí si ovšem nepředstavujme nějakou pevnou cestu. Naopak, je to standard zavádějící symbolická jména adresářů, která by měla být při psaní aplikací používána, aby byla zajištěna maximální variabilita aplikací a snadná údržba systému.

Standard důsledně odlišuje platformně závislá a nezávislá data a dokáže se vypořádat nejen s UNIXovými systémy, ale i s mnoha jinými standardy.

Symbolická jména adresářů (a jejich implicitní hodnoty)

prefix (/usr/local): Udává kořenový adresář balíku. O jeho volbě se ještě později rozepíšeme.

exec_prefix ($prefix): Udává kořenový adresář platformně závislých dat v balíku.

datadir ($prefix/share): Udává adresář pro platformně nezávislé datové soubory, které jsou po instalaci pouze ke čtení. Každý balík by si měl vytvořit podadresář; pokud bude instalovat jen jeden či dva soubory, může použít $datadir/misc.

sysconfdir ($prefix/etc): Udává adresář pro konfigurační soubory, tedy soubory, které balík používá pouze ke čtení, ale uživatel či konfigurační nástroj je může měnit.

localstatedir ($prefix/var): Udává adresář pro měnící se soubory. Zde se ukládají datové soubory, které uživatel nebude editovat, ale budou vznikat činností programu.

sharedstatedir ($prefix/com): Udává adresář pro měnící se soubory. Na rozdíl od localstatedir je určen pro soubory, které lze sdílet mezi různými stroji. Popravdě řečeno, neviděl jsem balík, který by tento adresář využil.

bindir ($exec_prefix/bin): Udává adresář, do kterého se budou umisťovat běžné spustitelné soubory).

sbindir ($exec_prefix/sbin): Udává adresář, do kterého se budou umisťovat spustitelné soubory, určené pro superuživatele).

libexecdir ($exec_prefix/li­bexec): Udává adresář, do kterého se budou umisťovat spustitelné soubory spouštěné jinými aplikacemi (typicky síťové démony pro inetd, pomocné spustitelné soubory apod.).

libdir ($exec_prefix/lib): Udává adresář pro knihovny.

includedir ($prefix/inclu­de), mandir ($prefix/man), infodir ($prefix/info): Udává adresář pro hlavičkové, man a info soubory.

Do seznamu se bohužel nedostal docdir. Jeho standardní cesta někdy bývá $prefix/doc, ale panuje zde nejednotnost.

Symbolickým jménům adresářů můžeme při spouštění skriptu configure přiřadit námi požadované hodnoty namísto implicitních. Slouží k tomu konfigurační volby –prefix, –exec-prefix a další podle výše uvedených názvů (s předřazenými –). Ty pak budou použity při instalaci.

Proměnné pro configure

Činnost configure lze ovlivnit proměnnými. Mezi nejdůležitější pat­ří:

CPPFLAGS: V této proměnné jsou uloženy doplňkové volby preprocesoru. Jedná se nejčastěji o dodatečné adresáře pro hledání hlavičkových souborů (např. -I/usr/include/fre­etype2).

LDFLAGS: Zde jsou analogicky uloženy doplňkové volby linkeru. Většinou jde o další adresáře pro hledání knihoven (např. -L/usr/lib/mysql). Lze jej též použít pro zadání speciálního způsobu linkování, nebo knihovny, která se přilinkuje ke všemu v balíku.

CFLAGS: No a sem zbydou ostatní volby kompilátoru, tedy především optimalizace (např. -O3 -fomit-frame-pointer). U špatně napsanách balíků je nutné do ní přidat i to, co by mělo být součástí CPPFLAGS nebo LDFLAGS.

Velmi speciální proměnnou je CONFIG_SITE definující adresu skriptu site (o tom viz dále).

Trochu mimo patří ACLOCAL_FLAGS. Jednak proto, že nezávisí na samotném configure, ale přebírá ho již jeho generátor (např. autogen.sh), a také proto, že jeho podpora není obecná. Hodí se tehdy, potřebujeme-li na vygenerování konfiguračního skriptu m4 makra z nějakého neobvyklého adresáře.

Nezapomeňte proměnné po nastavení vyexportovat pomocí export.

Proměnná DESTDIR pro make – základ pro tvorbu balíčků

Důležitou proměnnou pro make je DESTDIR. Je určena správcům balíčků. Nepředává se skriptu configure, ale programu make:

mkdir /tmp/instalace
make DESTDIR=/tmp/instalace install

Po instalaci máme všechny soubory pohromadě, jako by adresář DESTDIR byl kořenovým adresářem systému, a lze z nich snadno vytvořit distribuční balíček (pokud ovšem autor programu nepoužil k instalaci nesprávnou konstrukci). Toto je nejčistší způsob tvorby distribučních balíčků.

Proměnnou DESTDIR podporují všechny programy vytvořené pomocí nástrojů automake, ale i některé další.

Keš

Další důležitou schopností configure je kešování výsledků. Spouštíte-li skript podruhé, načte si předchozí výsledky z keše a testy již neprovádí znovu. Implicitně se jedná o soubor config.cache (u starších verzí auto nástrojů, novější verze generují implicitně configure s vypnutou keší), ale tuto hodnotu lze změnit konfiguračním parametrem -C nebo –config-cache. To významně urychluje konfiguraci (zvlášť pokud bychom si vytvářeli globální keš výsledků). Na druhou stranu objevíme-li v průběhu konfigurace nějaký problém a následně ho odstraníme, skript to nezjistí. Je proto nutné smazat buď řádek, ve kterém je výsledek testu uložen, nebo celý soubor keše.

Keš má však ještě jednu důležitou funkci – při křížové kompilaci umožní uchovat výsledky testů na cílovém počítači.

Křížová kompilace

Pro křížovou kompilaci slouží několik konfiguračních voleb: –build, –host a –target. Ty umožní kompilovat balík na jiném stroji, než na kterém bude použit. Je však nutné upozornit, že křížová kompilace je možná pouze u zcela korektně napsaných balíků (které podporují kešování všech testů, korektně odlišují pomocné binární programy použité při kompilaci od těch použitých při instalaci).

Skript site

Auto nástroje nabízejí ještě další možnost, jak zasáhnout do procesu konfigurace. Je jím skript /usr/local/sha­re/config.site, /usr/local/et­c/config.site nebo jiný, určený proměnnou CONFIG_SITE. Tento skript se spouští na počátku skriptu configure a můžeme jím ovlivňovat proces konfigurace pro všechny balíky. Jedná se především o cesty a použité optimalizace.

Zajímavou možností skriptu site je předat (či vnutit) výsledky testu.

Zde je ukázka jeho možností (předpokládám Bash za implicitní shell; skript si upravte podle svých potřeb):

# Instalovat implicitně do /usr
# (Používejte jen na systémech bez balíčkovacího systému,
# např. Linux From Scratch – LFS)
ac_default_prefix=/usr
# Standardně chtít dynamické knihovny a nechtít statické.
# (Pozor, vyřadí některé balíky z provozu,
# je pak nutné --enable-static)
: ${enable_shared:=yes}
: ${enable_static:=no}
# Netestovat, používáme-li GNU nástroje, a předpokládat, že ano.
ac_cv_prog_gcc=yes
ac_cv_prog_gnu_ld=yes
ac_cv_prog_gnu_as=yes
# Nechceme dynamické knihovny s ladicími symboly?
# Proto tvrdíme, že cc ani c++ neumí volbu -g!
: ${ac_cv_prog_cc_g:=no}
: ${ac_cv_prog_cxx_g:=no}
# Zapnout silnou optimalizaci.
# (Pozor, vyřadí některé balíky z provozu!)
CFLAGS="-O3 -fomit-frame-pointer $CFLAGS"
CXXFLAGS="-O3 -fomit-frame-pointer $CXXFLAGS"
# A budu používat GNU-FHS (viz dále).
. /usr/share/site/fhs.site

Pro ty, co jsou méně zběhlí v Bashi, připomínám, že konstrukce

: ${promenna:=hodnota}

přibližně odpovídá

if test "$promenna" = ""
then
    promenna="hodnota"
fi

FHS

FHS (Filesystem Hierrarchy Standard) je druhý standard, který má co do činění s adresáři. Určuje jednoznačné cesty k souborům podle typu.

Definuje jakési adresářové oblasti a v nich adresáře, které mají být při instalaci použity. Tam jsou pak vytvářeny podadresáře podle typu, podobně jako u GNU Coding Standards.

/: Do adresářů pod kořenovým adresářem se instalují pouze programy nutné pro start systému (jejich výčet je součástí FHS).

/usr: Tyto adresáře jsou hlavními systémovými adresáři. Spolu s kořenovým adresářem tvoří doménu správce balíčků a nemělo by sem být instalováno nic, co není vloženo do jeho databáze. Zdejší aplikace by měly používat adresáře /usr/share/man, /usr/share/info a /usr/share/doc. Adresář není určen pro vytváření podstromů (např. /usr/balík/bin, tím méně /usr/bin/balík, výjimkou je již existující /usr/X11R6).

/usr/local: Adresáře pro místní balíčky. Je dán plně k dispozici administrátorovi. Soubory odtud by měly mít ve všech cestách přednost před systémovými. Adresář není určen pro vytváření podstromů (např. /usr/local/ba­lík/bin). Zdejší aplikace zřejmě mohou v případě potřeby používat i adresáře /etc a /var, ovšem ze standardu FHS to není jasné a ani dotaz do konference mi to zcela neobjasnil.

/opt: Adresáře pro speciální účely. Je dán k dispozici administrátorovi (myšleno adresáře /opt/bin atd.) a je též určen pro vytváření podstromů (např. /opt/balík/bin). Zdejší aplikace mohou používat adresáře /etc/opt a /var/opt.

/opt/podstrom: V adresáři /opt lze vytvářet podstromy pro jednotlivé balíky nebo jejich skupiny. Je určen přednostně pro takové aplikace, které nepoužívají správce balíčků. Zdejší aplikace mohou používat adresáře /etc/opt/podstrom a /var/opt/podstrom. Různé podstromy mohou být vytvářeny různými uživateli nebo obsahovat různé verze téhož balíčku. Správa těchto adresářů se většinou provádí ručně – smazáním adresáře a uložením nového obsahu.

Podle poslední dostupné verze (2.2) není zatím jasné, kam by měly ukládat svá data veřejné síťové služby (www, ftp apod.), a vývojáři FHS se zřejmě ještě nedohodli.

Podpora adresářových oblastí pod /opt a její konkrétní podoba se může lišit podle distribuce.

Podrobnější popis FHS v češtině najdete např. na Linuxworldu.

GNU × FHS

Jak vidíme, GNU a FHS se sice zčásti podobají, ale v další části se liší. Projdeme-li si podadresáře doporučené dle FHS, nalezneme další změny.

V FHS nenajdeme libexec, jehož náhradou jsou adresáře sbin, pokud jsou instalovaná data povahy spustitelných dat, nebo lib, jsou-li data knihovní povahy. Nenajdeme zde ani sharedstatedir, jehož náhradou by snad mohla být var/cache.

Naproti tomu FHS definuje speciální strukturu pro hry – binární soubory do games, datové soubory do share/games a proměnná data do var/games.

Abychom vyhověli FHS, musíme změnit cíle použitých adresářů, např.:

root_podpora

./configure --prefix=/usr --localstatedir=/var\
  --sysconfdir=/etc

./configure --prefix=/opt/balik --localstatedir=/var/opt/balik\
  --sysconfdir=/etc/opt/balik

./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc\
  --mandir=/usr/share/man --infodir=/usr/share/info

A to ještě není zdaleka kompletní specifikace cest…

Aby byla konfigurace v jednotlivých adresářových oblastech jednodušší, vyrobil jsem malý skript – GNU-FHS. Pokud jej vložíte do svého site skriptu, zařídí správnou konfiguraci cest sám.

Byl pro vás článek přínosný?