Každá php extension je jedním modulem. Jak už jsem psal v předchozích částech, je modul sbírka funkcí, tříd, konstant atd. Modul se do PHP může dostat buď staticky, přímo se slinkuje s ostatními částmi PHP jako jediný celek, nebo dynamicky jako dynamická knihovna. Tu si pak uživatel můžeme přidat do PHP nejčastěji přes konfigurační direktivy v php.ini nebo pomocí funkce dl. Pokud píšeme extenzi do PHP platí pro modul pár zásad, které je třeba dodržet. První z nich je nutnost vytvořit konfiguraci pro kompilování modulu.

Když vytváříte nějakou PHP extension, je asi nejlepší jít cestou dynamické extenze. Dá se snadno testovat z adresáře, ve kterém máte zdrojové soubory extenze. Vývojáři PHP s tím dokonce počítají, pro testování dynamických extenzí je udělána v makefilu přímo podpora.

Doporučuji se nejdříve sestavit kostru modulu a tu si zkusit přeložit. Problém je trochu v tom, že k té kostře je toho potřeba docela dost a když něco chybí, dost špatně se hledá, co vlastně chybí. První věc je tedy konfigurace pro překlad modulu. PHP se drží klasické GNU autotools cesty, takže jde o soubor config.m4, kde kombinací shellu, autoconfu, automake atd. docílíte správné konfigurace pro kompilaci, slinkování a nainstalování vaší extenze. PHP vývojáři přidali do autoconfu některá makra, která vám ulehčí práci. Základní config.m4 pro jednoduchou extenzi bez použití externích knihoven je to, co je vidět v mé extenzi pro include path.

PHP_ARG_WITH(incpath, for OOP IncPath wrapper support,
[  --with-incpath          Include IncPath OOP wrapper support])

Makro PHP_ARG_WITH zajistí přítomnost přepínače ve vygenerovaném configure a pro podporu kompilace Vaší extenze.

if test "$PHP_INCPATH" != "no"; then
    PHP_NEW_EXTENSION(incpath, incpath.c, $ext_shared)
fi

Tady říkáte, že když si uživatel vybral kompilaci vaší extenze, tak jak se extenze bude jmenovat, jaké soubory jsou nutné k její kompilaci a že se bude jednat o sdílenou extenzi. Pokud děláte extenzi čistě jen jako PHP záležitost - není to wrapper nad nějakou C/C++ knihovnou - tak s tímto vystačíte. Pro wrapper máte v podstatě dvě možnosti.

Pokud je knihovna malá, tak je možné zdrojáky knihovny mít jako součást extenze, kompilovat to všechno jako jeden celek. Config.m4 pak zůstane v podstatě stejný, jen naroste definice souborů pro kompilaci. Takhle je to třeba s php extenzí pro dnes tak populární databázi mongodb.

Druhá možnost je kompilovat proti existující knihovně v systému. Tohle je ta správná voda na mlýn autoconfu, který je přesně na tohle určen. Zkontrolovat definované závislosti a provést testy tak, aby se komplilovalo a linkovalo s tím, s čím se má. Když něco chybí, tak zařvat. Tady už je to ale opravdu dost o tom znát shell a autoconf. Dost pomůže poučit se od ostatních, např. v geoIP extenzi je vidět, jak se kontroluje přítomnost hlavičkových souborů, vlastní knihovny, funkcí v knihovně atd.

Celá věc s config.m4 vyjde najevo v okamžiku, když spustíte phpize. To se pak ve Vašem adresáři s extenzí objeví hromada souborů z GNU autotools pro kompilaci (aclocal.m4, configure.in, libtool …), které jsou součástí systému, pokud jste instalovali php ze zdrojových souborů případně máte nějaký ten php-dev balíček. Váš config.m4 do nich krásně zapadne. Např. když spustíte configure --help uvidíte volbu pro kompilaci vaší extenze.

Jen tak na okraj, pár projektů - zejména celé KDE - začalo upouštět od klasického autotools a migrovat na cmake. Je pravda, že ta sbírka shellu a m4 mi tedy nebyla nikdy moc sympatická, tak uvidíme, jestli se toho někdy dočkáme i u php. V rámci GSOC už na to bylo vypsáno téma, zatím se ale nic zásadního neděje a určitě ještě dlouho nic dít nebude.

Příště až čas dovolí, tak už snad něco přímo ke zdrojáku modulu.