Ceux qui me connaissent et qui ont lu le post précédent ont peut-être cru à l’imposture: “. Basculement vers autoconf pour la génération du Makefile”
iMil ? c’est bien toi ?
Oui alors attention hein, pas d’affolement. Il s’agit réellement d’une utilisation très très light de ces outils que j’évite habituellement comme la peste. Tellement light que seul autoconf m’a été utile.
Mais reprenons. Ceux qui ont eu le courage de se plonger dans le code de pkgin se rappellent peut-être de ce genre de choses :
.if ${OPSYS} != "Linux"
LDADD+= -lssl
.endif
.if ${OPSYS} == "Darwin" || ${OPSYS} == "SunOS"
LDADD+= -lcrypto
.endif
.if ${OPSYS} == "DragonFly"
LDADD+= -lutil
.endif
.if ${OPSYS} == "SunOS" || ${OPSYS} == "Linux"
LDADD+= -lnbcompat
.endif
.if ${OPSYS} == "SunOS"
LDADD+= -lnsl -lsocket -lresolv
LDADD+= -Wl,-R -Wl,${LOCALBASE}/lib -L${LOCALBASE}/lib -lsqlite3
.else
LDADD+= -Wl,-rpath -Wl,${LOCALBASE}/lib -L${LOCALBASE}/lib -lsqlite3
.endif
etc etc etc…
Ces petites plaisanteries, c’est mignon lorsqu’on adresse une ou deux plateformes, mais à la longue, ça devient parfaitement inmaintebable. Et c’est là qu’intervient autoconf; plutot que de tester le système sur lequel nous oeuvrons puis déduire quelle librairie / header inclure, nous allons plutot tester l’existence de fonctions particulières au sein du système visé.
La première chose à faire, c’est d’utiliser la commande autoscan. Cette dernière créera un fichier configure.scan, soit une sorte de template destiné à devenir configure.ac. Dans ce template, des tests assez basiques sur l’existence de certains headers ou autres fonctions sont présents.
Exemple simple, la directive AC_CHECK_LIB permet de verifier si une fonction fait ou pas partie d’une librairie. Cette macro prend en premier paramètre le nom de la fonction recherchée, en second la librairie dans laquelle rechercher, le 3ème parametre permet d’affecter une action en cas de succès, le 4eme en cas d’échec et enfin le dernier d’ajouter des librairies au test. Fort heureusement, dans la plupart des cas, nous n’utiliserons pas plus de trois paramètres :
AC_SEARCH_LIBS([sqlite3_open], [sqlite3],,
AC_MSG_ERROR(SQLite3 not found.)
)
Dans l’exemple ci-dessus, on verifie que la fonction sqlite3_open existe bien dans la librairie libsqlite3, si tel n’est pas le cas -en particulier si la librairie elle même n’est pas présente ou pas trouvée-, nous arrêterons le script de configuration et afficherons un message d’erreur.
Notez que la macro AC_SEARCH_LIBS aura pour effet, en cas de succès, d’ajouter à la variable LIBS la librairie testée.
Et c’est bien là tout l’intérêt de la chose, car ce que nous souhaitons, c’est bénéficier d’un fichier Makefile générique qui se remplira des librairies-dépendances. En l’occurrence, c’est le fameux Makefile.in qui remplit cette fonction. En effet, à l’issue du non moins fameux configure, le fichier Makefile.in est complété avec les variables détéctées et le résultat publié dans un Makefile classique.
La bonne nouvelle, c’est que le Makefile.in peut tout à fait être sous la forme d’un BSD Makefile.
Voici par exemple un LDADD qui serait totalement complété par autoconf :
LDADD+= @LIBS@
Il y a des dizaines, des centaines, des milliers de tutoriaux sur les autotools un peu partout sur le web, mais à mon humble avis une bonne partie d'entre eux brillent par leur faculté à rendre ces outils aussi repoussants qu'imbuvables. Par chance, je suis tombé sur deux liens qui m'ont grandement aidé à comprendre ce que je faisais: le premier est un des configure.ac les mieux foutus qu’il m’ait été donné de voir, il s’agit de celui d’apachetop, et il est truffé de bons exemples.
le second ressemble à un slideware mais regroupe de manière synthetique des informations d’habitude noyées dans 500 pages de documentation soporifiques. On notera en particulier le slide 12 qui liste les principales variables substituées.
Un dernier exemple relatif à la substitution de variables :
# check for humanize_number
AC_CHECK_FUNC([humanize_number],,
# in DragonFly humanize_number is in libutil
AC_SEARCH_LIBS([humanize_number], [util],,
# don't have it, include humanize_number.c to SRCS
[SRCS="humanize_number.c $SRCS"]
)
)
AC_SUBST(SRCS)
Celui-ci est un tout petit peu plus complexe. Dans l’ordre, nous vérifions si la fonction humanize_number est présente dans la libc, si oui, nous ne faisons rien, autrement (notez les deux virgules), nous cherchons dans la libutil qui heberge cette fonction sous DragonFly BSD. Finalement, si nous ne trouvons toujours pas cette fonction, nous ajoutons le fichier humanize_number.c à la variable SRCS.
Cette variable n’étant pas automatiquement remplacée dans le fichier Makefile.in, nous indiquons à autoconf qu’il devra effectuer cette substitution grace à la macro AC_SUBST.
Finalement, à l’issue de l’ecriture du configure.ac et du Makefile.in associé, nous invoquons autoconf qui génèrera un script configure. L’execution de ce dernier produira un Makefile adapté à votre plateforme cible.
Convenient isn’t it ?
Recent Comments