Comparons ce qui est comparable. Pour certains de mes documents un peu complexes, j'ai besoin de retravailler l'index entre sa génération par xindy (ça serait pareil avec makeindex) et son inclusion dans le document. Le fait d'avoir une passe de génération et une passe d'inclusion permet. de faire tourner une moulinette maison entre les deux. Et cela vaut pour tous les fichiers annexes (bibliographie, index, liste des n'importe quoi, etc.). Le fait de fonctionner en plusieurs passes (pas seulement trois, cela peut être beaucoup plus en fonction de la complexité du document, l'utilisation de l'extension longtable peut imposer des passes supplémentaires, par exemple) et d'avoir ces fichiers annexes n'est pas une tare mais une force. Ceux qui n'ont pas besoin d'en profiter peuvent utiliser latexmk ou rubber, les autres peuvent en tirer parti.TLN a écrit :Oui non mais ok c'est une chose de devoir faire 3 passes pour produire un document final correct. C'est est une autre de devoir les faire manuellement parce que le programme qui compile (pdflatex ou latex) n'est pas foutu de deviner ça tout seul. Devoir passer par un script Python intelligent genre rubber c'est quand même pas moral.
Quand tu compiles ton code avec gcc en faisant des includes de la stl, tu recompiles pas 3 fois ton programme avec gcc avant qu'il puisse fonctionner ... =/
Pour revenir à la comparaison avec gcc, celui-ci est comparable à latexmk ou rubber, mais il cache en réalité cpp, cc1, as et ld de la même façon qu'on a latex, bibtex (ou biber) et xindy (ou makeindex).
latexmk -C (ou -c si on veut garder le fichier DVI ou PDF généré).TLN a écrit : Et je ne te parle même pas des 36 fichiers de logs que peut générer Latex. Ca non plus c'est pas moral. Devoir faire « rm -vf *.aux *.out *.log *.toc *.bbl *.blg *.lof *.nav *.snm *.vrb » pour retrouver un dossier propre après génération du pdf, c'est quand même pas normal xD
Je suppose que rubber dispose d'une option équivalente.
