Ce que j'appelle marcher/fonctionner, c'est qu'une fois la commande lancée, je suis certain d'obtenir un pdf final avec le bon nombre de passes. Le fait d'avoir à gérer les dépendances à la main est une première limite évidente : si j'ajoute une image et que j'oublie de l'inclure dans les dépendances, c'est mort. Ce n'est pas de que j'appelle fonctionner (en tout sûrement pas très bien).
Dans BSD Owl, c'est ajustable. Chaque passe a un nom, et la variable MULTIPASS énumère les passes à faire:
Le nombre de passe doit être déterminé par surveillance des messages émis par latex, c'est le seul moyen. En fonction de la source des modifications, latex doit faire plus ou moins de passes (par exemple, un ajout de référence engendre plus de passes qu'une modification du fichier bibtex). Il n'y aucun moyen simple de prévoir ce qui va se passer, notamment en raison des ajustements fins réalisés par certains packages (longtable en co) qui peuvent avoir des effets sur la table des matières. Ba oui, latex c'est compliqué. Et donc, le nombre de passes ne peut pas être fixé. Et donc, ça ne marche pas.
Peut-être que tu pourrais expliquer rapidement comment on utilise latexmk pour compiler un document contenant des figures ou une table générée par un script?
Je ne suis pas certain de bien comprendre la question. Je soupçonne que tu demandes comment intégrer latexmk dans un makefile. Si c'est le cas, je ne vois pas bien la difficulté, notamment parce que la compilation latex arrive toujours en dernier. Tu peux donc faire tout ce que tu veux avant, puis appeler latexmk. Cerise sur le gâteau, la compilation du document ne sera faite que si les éléments inclus (figure par exemple) ont vraiment été modifiés (au sens du contenu, pas de la date de modification). Il a aussi une fonctionnalité évoluée de latexmk qui lui permet d'intégrer des règles de transformation de documents voués à être inclus dans un source latex. Je n'a pas testé et je préfère un makefile dans ce cas là (qui utilise latexmk pour la compilation, bien sûr).
Pour le reste, sur make/bmake/gnumake je remarque au contraire de toi que la plupart des langages de programmation contemporains (scala, ruby, etc.) ont leur propre système de build pour plein de raisons : gestion complexe de dépendances, extensibilité dans le langage, etc. Mais tout ceci est totalement orthogonal au fait que ça fait au moins 20 ans (et oui) que je fais du latex et qu'on me montre des makefile divers et variés dont aucun ne résout efficacement le problème compliqué de la compilation du latex, alors que c'est le cas de latexmk. Encore une fois, je ne remets pas en question l'intérêt général de bmake, bsd owl ou tout ce que tu veux (je me tamponne, pour être honnête), je dis juste que ça ne peut pas marcher pour latex. C'est une question de modèle : latex n'est pas un pipeline source -> pdf/ps, il a des passes dynamiques. À ma connaissance, aucun builder généraliste n'est prévu pour ce genre de chose (je dis bien à ma connaissance).
Apparemment tu n'as pas lu le paragraphe Brouillons et traitements multiples.
Ah ba non, bien sûr, je ne lis surtout pas ce que je commente. C'est plus pratique pour dire n'importe quoi.
Dans mon expérience de la recherche et de l'écriture de documents, je suis amené à collaborer avec des personnes qui ne connaissent pas les SCM et ne souhaitent pas forcément apprendre leur fonctionnement. Et puis ceux qui connaissent les SCM ne veulent pas forcément apprendre tous les SCMs du monde.
Nous sommes d'accord, mais en quoi ça t'empêche d'utiliser localement celui que tu veux ?
Dans la pratique quand je montre un travail préliminare à des amis ou des collaborateurs, l'horodatage permet à ces derniers de facilement repérer d'entre plusieurs versions quelle est la plus récente. De mon côté, je peux utiliser la date pour retrouver la version correspondate dans mon SCM.
C'est exactement la même chose avec gitinfo2 mais avec la garantie induite par l'utilisation du gestionnaire de version de pouvoir revenir à la version concernée.
[^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
Posté par boubou . En réponse à la dépêche Préparation de documents LaTeX avec BSD Owl. Évalué à 4.
Ce que j'appelle marcher/fonctionner, c'est qu'une fois la commande lancée, je suis certain d'obtenir un pdf final avec le bon nombre de passes. Le fait d'avoir à gérer les dépendances à la main est une première limite évidente : si j'ajoute une image et que j'oublie de l'inclure dans les dépendances, c'est mort. Ce n'est pas de que j'appelle fonctionner (en tout sûrement pas très bien).
Le nombre de passe doit être déterminé par surveillance des messages émis par latex, c'est le seul moyen. En fonction de la source des modifications, latex doit faire plus ou moins de passes (par exemple, un ajout de référence engendre plus de passes qu'une modification du fichier bibtex). Il n'y aucun moyen simple de prévoir ce qui va se passer, notamment en raison des ajustements fins réalisés par certains packages (longtable en co) qui peuvent avoir des effets sur la table des matières. Ba oui, latex c'est compliqué. Et donc, le nombre de passes ne peut pas être fixé. Et donc, ça ne marche pas.
Je ne suis pas certain de bien comprendre la question. Je soupçonne que tu demandes comment intégrer latexmk dans un makefile. Si c'est le cas, je ne vois pas bien la difficulté, notamment parce que la compilation latex arrive toujours en dernier. Tu peux donc faire tout ce que tu veux avant, puis appeler latexmk. Cerise sur le gâteau, la compilation du document ne sera faite que si les éléments inclus (figure par exemple) ont vraiment été modifiés (au sens du contenu, pas de la date de modification). Il a aussi une fonctionnalité évoluée de latexmk qui lui permet d'intégrer des règles de transformation de documents voués à être inclus dans un source latex. Je n'a pas testé et je préfère un makefile dans ce cas là (qui utilise latexmk pour la compilation, bien sûr).
Pour le reste, sur make/bmake/gnumake je remarque au contraire de toi que la plupart des langages de programmation contemporains (scala, ruby, etc.) ont leur propre système de build pour plein de raisons : gestion complexe de dépendances, extensibilité dans le langage, etc. Mais tout ceci est totalement orthogonal au fait que ça fait au moins 20 ans (et oui) que je fais du latex et qu'on me montre des makefile divers et variés dont aucun ne résout efficacement le problème compliqué de la compilation du latex, alors que c'est le cas de latexmk. Encore une fois, je ne remets pas en question l'intérêt général de bmake, bsd owl ou tout ce que tu veux (je me tamponne, pour être honnête), je dis juste que ça ne peut pas marcher pour latex. C'est une question de modèle : latex n'est pas un pipeline source -> pdf/ps, il a des passes dynamiques. À ma connaissance, aucun builder généraliste n'est prévu pour ce genre de chose (je dis bien à ma connaissance).
Ah ba non, bien sûr, je ne lis surtout pas ce que je commente. C'est plus pratique pour dire n'importe quoi.
Nous sommes d'accord, mais en quoi ça t'empêche d'utiliser localement celui que tu veux ?
C'est exactement la même chose avec gitinfo2 mais avec la garantie induite par l'utilisation du gestionnaire de version de pouvoir revenir à la version concernée.