Sommaire
Améliorer PHP 4.0
Préface
Présentation
Capacités d'extensions
Disposition du code source
Le système de compilation automatique de PHP
Créer une extension
Utiliser une extension
Résolution de problèmes
Présentation des sources
Gestion des arguments
Créer des variables
Afficher des informations
Valeurs retournées
|
7.5 Le système de compilation automatique de PHP
PHP 4 dispose d'un système automatique de compilation particulièrement
souple. Tous les modules sont placés dans des sous dossiers du dossier
ext
. En plus de ses propres sources,
chaque module est constitué d'un fichier M4 (par exemple, voyez
http://www.gnu.org/manual/m4/html_mono/m4.html)
pour la configuration et un fichier Makefile.in
, qui est
responable de la compilation (le résultat d'autoconf et automake; Par
exemple, voyez
http://sourceware.cygnus.com/autoconf/autoconf.html
et http://sourceware.cygnus.com/automake/automake.html).
Tous les fichiers sont générés automatiquement, ainsi que le
.cvsignore
, par un petit script schell
appelé ext_skel
qui est placé dans le dossier
ext
. Il prend comme argument le nom du
module que vous souhaitez créer. Le script shell crée alors
le dossier du même nom, ainsi que les fichiers
config.m4
et Makefile.in
ad hoc.
Pas à pas, le processus de création de module est le suivant :
root@dev:/usr/local/src/php4/ext > ./ext_skel my_module
Creating directory
Creating basic files: config.m4 Makefile.in .cvsignore [done].
To use your new extension, you will have to execute the following steps:
$ cd ..
$ ./buildconf
$ ./configure # (your extension is automatically enabled)
$ vi ext/my_module/my_module.c
$ make
Repeat the last two steps as often as necessary.
Ces instructions crée les fichiers susmentionnés. Pour inclure le
nouveau module dans le processus automatique de configuration et
compliation, vous devez exécuter buildconf
,
qui regénère le script configure
en analysant
le dossier ext
, et en incluant tous les fichiers
config.m4
qu'il trouve.
Enfin, exécuter configure
analyse toutes les
options de configuration, et génére un fichier Makefile
,
avec ces options, et celles que vous avez spécifiés dans Makefile.in
.
<>shows the previously generated
Makefile.in
:
Fichier Makefile.in
par défaut |
# $Id: Extending_Zend_Build.xml,v 1.6 2002/03/25 08:13:46 hholzgra Exp $ LTLIBRARY_NAME = libmy_module.la LTLIBRARY_SOURCES = my_module.c LTLIBRARY_SHARED_NAME = my_module.la include $(top_srcdir)/build/dynlib.mk
|
Il n'y a pas grand chose à dire à propos de celui-ci. Il contient
les noms des fichiers d'entrée et de sortie. Vous pouvez aussi
spécifier des instructions de compilation pour d'autres fichiers, si
votre module est compilé avec différents fichiers source.
Le fichier config.m4
par défaut, illustré
ci-dessous, est un peu plus complexe.
Fichier config.m4
par défaut |
dnl $Id: Extending_Zend_Build.xml,v 1.6 2002/03/25 08:13:46 hholzgra Exp $ dnl config.m4 for extension my_module dnl don't forget to call PHP_EXTENSION(my_module) dnl If your extension references something external, use with: PHP_ARG_WITH(my_module, for my_module support, dnl Make sure that the comment is aligned: [ --with-my_module Include my_module support]) dnl Otherwise use enable: PHP_ARG_ENABLE(my_module, whether to enable my_module support, dnl Make sure that the comment is aligned: [ --enable-my_module Enable my_module support]) if test "$PHP_MY_MODULE" != "no"; then dnl Action.. PHP_EXTENSION(my_module, $ext_shared) fi
|
Si vous n'êtes pas familiers avec les fichiers M4
(maintennt semble être un bon moment pour le devenir), cela peut être
compliqué au premier abord; mais c'est en fait très simple.
Note: Tout ce qui est préfixé avec
dnl est considéré comme un commentaire, et n'est
pas traité.
Le fichier config.m4
est responsable de l'analyse
des arguments de ligne de commande passé au fichier
configure
, au moment de la configuration. Cela signifique
qu'il va vérifier la présence des fichiers externes nécessaire, et
réaliser des opérations de configuration et paramétrage.
Le fichier par défaut crée deux directives de configuration dans le
script configure
:
--with-my_module et --enable-my_module.
Utilisez la première option pour faire référence à des fichiers
externes (comme par exemple, la directive --with-apache
qui fait référence au dossier Apache). Utilisez la seconde directive
lorsque l'utilisateur n'a qu'a décider d'activer votre extension. Indépendamment
de l'option que vous utilisez, il faut décommenter l'autre
directive. C'est à dire, si vous utilisez --enable-my_module,
pensez à supprimer le support de --with-my_module, et
vice versa.
Par défault, le fichier config.m4
créé par
ext_skel
accepte les deux directives, et automatiquement
active votre extension. Activer une extension est fait en utilisant
la macro PHP_EXTENSION. Pour changer
le comportement par défaut, pour que l'extension soit inclus dans
le binaire uniquement sur demande explicite de l'utilisateur,
(en utilisant l'option --enable-my_module ou
--with-my_module), changez le test de
$PHP_MY_MODULE en == "yes":
if test "$PHP_MY_MODULE" == "yes"; then dnl Action.. PHP_EXTENSION(my_module, $ext_shared) fi
Cela vous obligera à utiliser
--enable-my_module a chaque configuration et
recompilation de PHP.
Note: Be sure to run
buildconf
every time you change
config.m4
!
We'll go into more details on the M4 macros available to your
configuration scripts later in this chapter. For now, we'll simply
use the default files. The sample sources on the CD-ROM all have
working config.m4
files. To include them into
the PHP build process, simply copy the source directories to your
PHP ext
directory, run
buildconf
, and then include the sample modules
you want by using the appropriate --enable-*
directives with configure
.
|