Principe
Quand on compile un document .tex il faut en général procéder à plusieurs compilations : avec LaTeX, puis avec biber, puis avec makexindex etc.
Latexmk permet d’automatiser ces compilations, en vérifiant à la suite de chaque compilation qu’elle doit être la prochaine compilation, et en regardant les fichiers auxiliaires (.aux, .bbl etc) pour voir s’ils changent entre les compilations, et donc s’il est nécessaire de procéder à plusieurs compilations.
Prenons un exemple simple : un fichier .tex sans bibliographie et sans index, mais avec un table des matières.
latexmk va d’abord compiler avec LaTeX. Puis il va voir qu’un fichier .toc est produit, ainsi qu’un fichier .aux. Il va alors procéder à une seconde compilation, et regarder si ces fichiers ont changé. Si il y a eu un changement, il va procéder à une troisième compilation et vérifier si ces fichiers ont changé. etc. Ainsi jusqu’à cinq fois (par défaut). Si au bout de la cinquième série de compilation les fichiers ont encore changé, il considère qu’il est impossible d’avoir des fichiers stables [1].
Maintenant imaginons que j’ajoute une bibliographie. Latexmk va pouvoir analyser à la première compilation LaTeX, en fonction des fichiers produits (le fichier bbl notamment) qu’il existe une biblio, qui réclame Biber (ou bibtex). Et il va automatiquement compiler avec biber (ou bibtex après la première compilation LaTeX, puis il procédera à une seconde compilation LaTeX etc.
Autrement dit, Latxmk est capable de mettre en œuvre les séries successives de compilation, et surtout de savoir quand il est nécessaire de procéder à une nouvelle compilation.
Mise en œuvre : 1er essai
Latexmk est installé par défaut avec les différentes distributions LaTeX. Donc rien à installer.
Avec son Terminal, se rendre dans le dossier où se trouvent les fichiers à compiler [2].
Puis frapper latexmk nom_du_fichier_a_compiler. latexmk se lance et vous indique qu’il tente une première compilation :
Run number 1 of rule 'latex'
Il nous indique donc qu’il essaie de lancer la règle latex.
Qu’est-ce qu’une règle ? Une règle, c’est une suite d’opération nécessaire à la transformation d’un fichier a, par exemple un fichier .tex en un fichier b, par exemple un fichier .pdf, ou en l’occurrence un fichier .dvi (Je parles de ce fichier un peu plus bas.)
En l’occurence, la règle dit qu’il faut lancer le programme latex.
C’est ce qui se passe. Et là, patatra si vous utilisez XeLaTeX, avec le package fontspec vous obtenez un joli message The fontspec package requires either XeTeX or LuaTeX to function. et la compilation s’arrête là.
Logique : latexmk a essayé de compiler avec latex alors qu’il faudrait compiler à xelatex.
Il va donc falloir modifier le fonctionnement de latexmk, grâce à un fichier nommé latexmkrc à mettre dans le même dossier que les sources à compiler [3].
Syntaxe de base du fichier latexmkrc
Un tel fichier se compose d’une série de couple propriété / valeur. Chaque couple s’écrit une ligne avec la syntaxe suivante :
$proprieté = "valeur";
Première propriété : demander un fichier pdf
Il faut savoir qu’historiquement, LaTeX ne produisait pas de fichier .pdf, mais des fichiers .dvi. Ce n’est qu’avec le compilateur pdflatex qu’il a commencé à produire des fichiers .pdf.
La règle latex cherche à produire des .dvi.
Aujourd’hui, le .pdf est plus pertinent que le .dvi.
Nous allons donc mettre dans le fichier latexmkrc une demande de produire des fichiers .pdf.
Même si vous utilisez XeLaTeX, cette demande est très importante. En effet XeLaTeX ne produit pas des dvi mais que des pdf. Or si vous laisser les réglages par défaut, latexmk cherche à produire des dvi et n’y arrive pas.
Cette propriété, c’est pdf_mode. Si elle est égale à 1, alors latexmk va chercher à générer un pdf en utilisant la règle pdflatex.
Pour changer cette propriété, nous ajoutons donc à notre fichier latexmkrc :
Par ailleurs, par défaut cette règle pdflatex utilise le script pdflatex et non pas xelatex. Nous allons donc modifier cette règle, par la propriété pdflatex.
Deuxième propriété : utiliser XeLaTeX
La propriété pdflatex reçoit le nom de la commande à exécuter. En l’occurrence, pour nous il s’agit de xelatex.
Nous écrivons donc dans notre fichier :
On peut désormais lancer latexmk sans avoir d’erreur de compilation, puisque celui-ci va appeler la commande xelatex.
Par ailleurs, si une bibliographie est ajoutée, latexmk va lancer automatiquement biber ou biblatex, en choisissant lui-même le bon programme.
Troisième propriété : la génération de l’index
Lorsque latexmk détecte la création d’un fichier .idx, il sait qu’il s’agit d’un fichier d’index « brut », et qu’il faut le compiler pour obtenir des fichiers formatés.
Par défaut, il utilise makeindex. Mais on peut souhaiter utiliser splitindex lorsqu’on utilise le package splitidx pour avoir plusieurs index.
Il faut dire d’utiliser splitindex modifier la règle makeindex.
Nous pouvons donc mettre :
Seulement cela pose un problème.
En effet, si j’ai un fichier principal.idx, latexmk s’attend que la règle makeindex produise un fichier principal.ind. Or splitindex produit des fichiers principal-xxx.ind, mais pas de fichier principal.ind.
La solution consiste à dire que la règle makeindex exécute plusieurs commandes : makeindex puis splitindex. Pour cela, il suffit de séparer chaque commande par un point virgule. Ce qui donne
Problème : dans ce cas la commande makeindex ne vas pas s’exécuter sur le bon fichier. Il est donc nécéssaire de préciser le fichier sur lequel executer makeindex.
Pour cela, on utilise la notation %S, qui correspond au fichier source. Par exemple, dans le cas de la règle makeindex, il s’agit du fichier .idx, mais dans le cas de la règle pdflatex il s’agit du fichier .tex.
Donc cela donne :
Et si j’utilise le script de gestion de l’index des sources primaires
Ce script que j’utilise pour la gestion de l’index des sources primaires [4] nécessite d’être appelé avant splitindex
Je serais tenté de faire :
Seulement voilà, cela entraîne latexmk à tourner en rond. Pourquoi ? Si je ne me trompe la raison est la suivante. Lorsque latexmk applique une règle, il regarde le contenu des fichiers générés par cette règle avant qu’elle soit appliquée et après son application. Si ces fichiers ont changé, il considère qu’il faudra réappliquer la règle.
Donc dans mon cas cela donne (en sautant les règles biber) :
- Règle
pdflatex, compilation avecxelatex, création du fichier.idx - Règle
makeindex, modification du fichier.idx, via mon script python. - Règle
pdflatexqui modifie à nouveau le fichier.idx.
Le fichier .idx a été transformé à l’issue de la deuxième application de la règle pdflatex, puisqu’on est passé d’un fichier qui avait subit le script python à un fichier qui ne l’a pas subit.
Donc latexmk se dit qu’il faudra réappliquer la règle pdflatex, mais aussi la règle makeindex, puisque celle-ci cherche à transformer les fichiers .idx.
Et comme la règle makeindex modifie, si j’y intègre le script python, le fichier .idx, on tourne en rond.
La solution est donc de mettre le script python n’ont pas au début de la règle makeindex mais à la fin de la règle pdflatex.
Donc non pas :
mais :
Récapitulatif
Au final, mon fichier latexmrc contient les lignes suivantes :
Un plus : les entrées bibliographiques indéfinies et les références introuvables
À la fin de l’exécution de latexmk, celui ci nous indique les entrées bibliographiques absentes de la base de donnée et les \label manquants :
En revanche, il ne mentionne pas les \label en nombre multiples.