Préparation de documents LaTeX avec BSD Owl

Posté par Michaël (site web personnel) le 31 octobre 2014 à 00:25. Édité par BAud, palm123, Snark et Benoît Sibaud. Modéré par bubar🦥. Licence CC By‑SA.

Étiquettes :

oct.

2014

À l'occasion de la sortie de BSD Owl 2.2.1 — le système de compilation portable pour BSD Make — je vous propose d'apprendre à utiliser BSD Owl pour préparer et publier vos documents LaTeX.

Ce texte est une traduction de la page du Wiki “Producing LaTeX documents”.

Sommaire

Préparer des documents avec LaTeX
Avertissement: travailler avec TeX ou LaTeX
Avertissement: BSD Make
Utilisation simple
Fonctions avancées
Contribuer

Préparer des documents avec LaTeX

Vous apprendrez dans ce texte comment utiliser les scripts BSD owl (bsdowl) pour :

préparer des documents simples et les publier dans l'arborescence des fichiers;
préparer la bibliographie de vos documents LaTeX avec BIBTeX;
préparer des figures pour vos documents avec METAPOST;
gérer des documents dont certains éléments doivent être automatiquement régénérés;
gérer des documents dispersés dans différents répertoires.
gérer des collections comportant un grand nombre de documents.

Avertissement: travailler avec TeX ou LaTeX

Il y a de nombreux formats TeX, plain TeX et LaTeX en sont deux exemples. Le format LaTeX jouit d'une grande popularité et nous avons choisi d'utiliser le module latex.doc.mk dans les exemples. Cependant, ce qui suit s'applique aussi au module tex.doc.mk. Certains paragraphes dans la suite identifient les mécanismes spécifiques à latex.doc.mk.

Avertissement: BSD Make

Ne vous trompez pas de version de make : la plupart des distributions Linux installent GNU Make comme programme make principal, la version BSD de make est souvent appelée bmake et installable via un paquet du même nom. Sous les BSD, on trouve naturellement BSD Make comme commande make. Sous Mac OS X, c'est le programme bsdmake.

Utilisation simple

La préparation d'un document simple avec LaTeX est en elle-même particulièrement simple, l'utilisation de bsdowl pourrait donc sembler une complication inutile. Cependant, même dans ce cas, l'utilisation de bsdowl rend d'appréciables services, comme l'installation et l'horodatage des fichiers produits.

Néanmoins, la partie vraiment intéressante se situe dans la partie avancée.

La première fois

Supposons que le fichier script.tex contient notre texte et mettons-le dans un répertoire dédié. Créons un fichier Makefile (la majuscule compte) qui contient :

DOC = script.tex
.include "latex.doc.mk"

de sorte que le répertoire dédié contient maintenant script.tex et ce Makefile. Rendons-nous avec un shell dans ce répertoire et tapons make:

% make
make build
===> Multipass job for script.dvi (aux)
latex script.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./script.tex
LaTeX2e <2003/12/01>
...

S'il n'y avait pas d'erreur dans script.tex, on se retrouve avec les fichiers "compilés" suivants dans le répertoire courant :

% ls
Makefile    script.log
script.aux  script.tex
script.dvi  script.toc

Lorsque les produits de compilation ne sont plus nécessaires, vous pouvez nettoyer le dossier de travail avec le mantra make clean:

% make clean
rm -f  script.dvi script.log script.aux script.toc

Le nettoyage du dossier de travail est une étape optionnelle qui évite de voir son dossier personnel rempli de données inutiles, qui peuvent rapidement être recréées. Les fichiers DVI sont habituellement très petits, de l'ordre de quelques centaines de kilobits, mais les fichiers PostScript ou PDF sont habituellement bien plus gros.

Installation ou publication

Avant de nettoyer votre dossier de travail avec le mantra make clean, vous pouvez vouloir copier ce document à un emplacement approprié du système de fichiers. Cette étape s'appelle installation du document, car elle est analogue à l'installation d'un programme nouvellement compilé. Vous installez le document grâce à la commande make install mais il faut auparavant dire à make quel emplacement du système de fichiers est approprié. Il faut pour cela assigner à la variable DOCUMENTDIR le chemin du dossier où vous voulez que vos fichiers soient copiés, comme l'illustre le Makefile suivant :

DOCUMENTDIR = ${HOME}/doc/report
DOC = script.tex
.include "latex.doc.mk"

Vous pouvez alors passer à la commande make install:

% make install
install -d /home/michi/doc/report
install -o michi -g michi -m 440 script.dvi /home/michi/doc/report

En comparaison avec la copie manuelle du document produit, vous vous épargnez la saisie récurrente du dossier de destination après chaque mise à jour du document. Mais confier cette tâche élémentaire au Makefile a d'autres avantages plus importants :

Cela simplifie l'organisation de votre bibliothèque de sources pour vos documents.
Cette stratégie s'adapte à une collection importante de documents, cf. Travailler avec une collection de documents plus bas.
En mode brouillon, un suffixe horodatant le fichier est automatiquement ajouté, comme expliqué plus bas.

Choix du format de sortie

La chaîne de production TeX est capable de produire des documents électroniques dans plusieurs formats, comme DVI, PostScript (PS) ou PDF. La variable TEXDEVICE commande le choix du format de sortie des documents préparés avec latex.doc.mk. Cette valeur est généralement dvi de sorte qu'un fichier DVI sera préparé à partir du document source. D'autres valeurs possibles sont ps ou pdf. Si vous avez configuré une imprimante PostScript avec texconfig(1), disons TEXPRINTER, vous pouvez utiliser ps.TEXPRINTER comme valeur de TEXDEVICE ce qui indique à dvips d'utiliser les réglages pour TEXPRINTER dans la traduction de DVI vers PostScript. Il est enfin possible d'assigner une liste de formats de sortie à TEXDEVICE.

Brouillons et traitements multiples

Certains formats — dont LaTeX — et certaines macros exigent de votre manuscrit qu'il soit traité plusieurs fois par TeX ou LaTeX avant que vous n'obteniez la version finale. Le module latex.tex.mk impose un traitement à multiples passes de votre manuscrit, car LaTeX s'appuie sur ce mécanisme pour produire les références croisées associées aux commandes label ou ref de votre manuscrit. Le module doc.tex.mk ne procède pas à un traitement multiple.

Dans les premiers jets d'un document, les modifications sont probablement fréquentes ; il est donc souhaitable d'éviter de longs traitements multiples. bsdowl a un mode brouillon, activé en assignant la valeur yes à la variable DRAFT de make. Ceci peut être fait en ajoutant la commande suivante dans le Makefile:

DRAFT?= yes
DOC = script.tex
.include "latex.doc.mk"

La commande DRAFT?= est une forme faible de l'assignement qui permet d'invoquer make DRAFT=no pour rétablir le traitement à plusieurs passes pour une unique invocation de make, sans modifier le Makefile.

Lorsque les derniers ajustements ont été faits au manuscrit, vous pouvez supprimer la commande manipulant DRAFT et votre texte est prêt pour une dernière exécution de make produisant la version finale de votre document. Si vous en êtes satisfait, vous pouvez l'installer.

Pendant la mise au point d'un document, il est utile de garder des copies des documents produits à certaines étapes de votre travail. Imaginez envoyer un exemplaire préliminaire de votre travail à un ami qui le lira attentivement et vous fera part de ses commentaires. Pendant ce temps, vous continuez de travailler sur votre texte, si bien que lorsque vous recevrez ses commentaires, votre document aura évolué. Pour pouvoir comparer les commentaires de votre ami à la version de votre document que vous lui avez envoyé, la meilleure manière de résoudre ce problème est probablement d'utiliser un outil de gestion des versions — un logiciel gardant note des différentes révisions d'un fichier. Si vous n'utilisez pas un tel système et désirez en essayer un, vous pourriez être intéressé par GIT, tout particulièrement si vous utilisez les courriels pour organiser votre collaboration.

Lorsque la variable DRAFT est positionnée à yes et la variable TEXDRAFTSTAMP n'est pas initialisée, elle reçoit la valeur -${TEXDRAFTTIMESTAMP} où le texte de remplacement de TEXDRAFTTIMESTAMP est la date à laquelle la commande make est appelée. Lorsque la variable TEXDRAFTSTAMP est initialisée et n'est pas vide, son texte de remplacement est ajouté à la fin de tous les documents installés par latex.doc.mk ou tex.doc.mk. Si vous ne souhaitez pas que le nom soit modifié, tout en utilisant le mode brouillon, il suffit d'affecter un texte vide à TEXDRAFTSTAMP.

Un document dans plusieurs fichiers

Si vous travaillez sur un document complexe, vous aurez certainement découpé votre manuscrit en plusieurs fichiers ; typiquement, un fichier par chapitre ou par section plus un fichier principal contenant le préambule et de multiples commandes input demandant à LaTeX de lire tous les fichiers représentant le véritable contenu du document.

Supposons donc que votre document est découpé entre un fichier principal galley.tex et deux fichiers part1.tex et part2.tex. Votre galley.tex ressemble probablement à ceci :

\documentclass{article}
\begin{document}
\input{part1}
\input{part2}
\end{document}

Le Makefile correspondant est alors :

DOC = galley.tex
SRCS = part1.tex
SRCS+= part2.tex
.include "latex.doc.mk"

Fonctions avancées

Figures avec METAPOST

Les modules latex.doc.mk et tex.doc.mk prennent en charge
METAPOST agréablement. C'est un point particulièrement important à relever, car METAPOST est souvent l'outil le mieux adapté pour tracer des figures destinées à l'inclusion dans un document TeX. Cependant, il n'est que rarement pris en charge de façon adéquate par les interfaces graphiques LaTeX.

Ces modules font l'hypothèse que votre code METAPOST contient les lignes :

prologues := 3;
outputtemplate := "%j-%c.mps";

La première déclaration paramètre l'inclusion des fontes dans le fichier résultat tandis que la seconde change le format des noms utilisés par les produits.

Supposons donc que vous ayez préparé les illustrations pour votre article avec METAPOST et réparti ces illustrations dans deux fichiers illustr1.mp et illustr2,mp. Pour indiquer à latex.doc.mk qu'il doit les utiliser pour produire leurs figures, définissez la variable FIGS dans votre Makefile:

DOC = galley.tex
SRCS = part1.tex
SRCS+= part2.tex
FIGS = illustr1.mp
FIGS+= illustr2.mp
.include "latex.doc.mk"

Saisissez donc make à l'invite de commande. Le module latex.doc.mk analysera vos fichiers pour savoir quelles illustrations sont définies dans vos fichiers et produira les fichiers nécessaires à votre TEXDEVICE. Par exemple, si votre TEXDEVICE est dvi et que illustr1.mp contient la description de deux figures définies par beginfig(1) et beginfig(2), alors vous obtiendrez quatre fichiers :

% ls *.mps
illustr1-1.mps
illustr1-2.mps
illustr1-1.eps
illustr1-2.eps

Les deux premiers fichiers sont la sortie de METAPOST, des données intermédiaires dans un format PostScript spécifique. Les deux derniers sont en Encapsulated PostScript et adaptés à l'inclusion dans votre document.

En utilisant le paquet graphicx, l'inclusion d'image est aussi simple que possible :

\includegraphics{illustr1-1}%

Découvrez METAPOST. Il semblerait que de nombreuses personnes ne connaissent pas METAPOST. Si c'est votre cas mais que vous êtes intéressé par la découverte de cet outil merveilleux, la première bonne nouvelle est qu'il fait partie de la plupart — sinon de toutes — les installations de TeX, il est donc probablement déjà installé sur votre système.

La seconde bonne nouvelle est que de nombreuses informations peuvent être trouvées à son sujet sur le Web. Par exemple le TeX users group a une page dédiée à cet outil. La liste qui s'y trouve est particulièrement longue, j'ajouterai donc que j'ai lu et apprécié l'introduction de André Heck, elle est peut-être un bon point de départ pour vous !

Enfin n'oubliez pas d'essayer mon projet Metapost blueprint pour produire de splendides graphiques pour accompagner vos projets.

Bibliographie

bsdowl peut vous aider à préparer des bibliographies avec BibTeX. Tout d'abord vous devez vous assurer que TeX trouvera les base de données bibliographiques que vous avez énumérées dans vos commandes bibliography. Il est habituel de regrouper ses bases de données bibliographiques dans un dossier, par exemple ${HOME}/share/bib. Pour permettre à bibtex de trouver ses fichiers, il suffit d'ajouter le chemin ${HOME}/share/bib au contenu de la variable BIBINPUTS. Si votre base de données bibliographiques est dispersée dans plusieurs dossiers, vous n'avez qu'à mentionner chacun d'eux dans BIBINPUTS :

DOC = galley.tex
SRCS = part1.tex
SRCS+= part2.tex
BIBINPUTS = ${HOME}/share/bib
BIBINPUTS+= ../morebib
.include "latex.doc.mk"

Notez que le mantra make clean laissera intacts les fichiers BBL produits par bibtex. Les éditeurs demandent parfois de leur envoyer ces fichiers, ainsi, la commande make clean ou make distclean placera votre dossier de travail dans un état où vous pourrez facilement le redistribuer. Pour vous débarrasser des fichiers BBL, vous devez vous en remettre au puissant mantra make realclean.

Plusieurs documents dans le même dossier

Bien qu'il soit souvent une bonne idée de réserver un dossier à chaque document, vous pouvez avoir des raisons de vouloir travailler avec plusieurs documents dans le même dossier. Vous avez vos raisons et elles sont probablement excellentes, et bsdowl fera donc de son mieux pour vous aider.

Supposons que vous ayez deux documents dont les sources se trouvent dans le même dossier, disons un article et une version abrégée de cet article. Ces deux documents ont en commun un fichier macro.tex, mais sont à part cela relativement indépendants du point de vue de LaTeX. Le texte de l'article est divisé dans deux fichiers section1.tex et section2.tex. Le résumé a un seul fichier summary.tex. Le Makefile correspondant ressemble à ceci :

DOC = article.tex
DOC+= summary.tex

SRCS = macros.tex

SRCS.article.tex = section1.tex
SRCS.article.tex+= section2.tex

.include "latex.doc.mk"

Génération automatique d'une portion de document

Supposons que vous travailliez sur un document contenant une table dont le contenu changera vraisemblablement plusieurs fois et devra donc être mis à jour. Une telle table pourrait être un budget : lorsque notre situation évolue, ainsi en va-t-il de notre budget. Il peut être assez délicat de saisir une table en LaTeX, la mettre à jour est encore plus vachard. Dans cette situation, on peut écrire et utiliser à profit un petit programme lisant les données brutes de notre budget et écrivant pour nous le code LaTeX de la table correspondante, contenant cette information brute et les données que nous pouvons en dériver. Écrire un tel programme est très facile, car on a seulement besoin de savoir travailler avec des fichiers texte.

Ainsi, vous avez rassemblé vos données brutes pour votre table dans le fichier table.raw et écrit un petit programme gentable qui écrit pour vous la table LaTeX sur sa sortie standard. Dans votre manuscrit, vous utilisez le nom table pour inclure le contenu de la table. Voici votre Makefile:

DOC = galley.tex

table.tex: gentable table.raw
    ./gentable < table.raw > table.tex

REALCLEANFILES+= table.tex

.include "latex.doc.mk"

Cet exemple suppose que le programme gentable est un filtre, de sorte que l'entrée et la sortie sont effectuées par des redirections. D'autres programmes peuvent utiliser une convention différente pour définir la sortie et l'entrée.

Si vous envoyez vos fichiers à quelqu'un, cette personne ne voudra probablement pas exécuter votre programme gentable . Il semble donc préférable d'ajouter le nom du produit table.tex à REALCLEANFILES plutôt qu'à CLEANFILES : vous pouvez ainsi nettoyer votre dossier de travail avec make clean et faire une archive du contenu que vous enverrez à un tiers, sans avoir besoin de traiter le fichier table.tex avec une attention particulière.

Bien sûr, vous pouvez générer un code source pour METAPOST, typographier un fragment de code ou bien encore autre chose, au lieu de générer une table !

Code source réparti dans plusieurs répertoires

Certaines méthodes de travail requièrent que vos fichiers source ne soient pas situés dans un répertoire unique mais disséminés dans le système de fichiers.

Une raison pour travailler ainsi pourrait être que votre organisation utilise pour son courrier une classe de document personnalisée incluant quelques images. Vous ne souhaitez pas copier ces images dans chacun des dossiers utilisant cette classe de document, ni créer des liens symboliques vers ces images : vous souhaitez tout bonnement pouvoir ignorer leur existence ! Une solution à ce problème passe par la variable TEXINPUTS dont le contenu est une liste de dossiers que TeX doit examiner lorsqu'il recherche un fichier.

Une autre raison motivant la dissémination de fichiers sources dans plusieurs dossiers est la préparation d'un grand document, comme un livre. Si les fichiers de chaque chapitre sont contenus dans un dossier dédié, il est facile de traiter un chapitre isolé avec LaTeX pendant la phase de mise au point du manuscrit. TeX doit donc trouver tous les fichiers nécessaires lorsqu'il traite le fichier principal produisant le livre, ce qui est accompli en positionnant TEXINPUTS à la valeur adéquate, comme expliqué ci-dessous.

Vous pouvez définir la variable TEXINPUTS dans votre environnement, dans votre Makefile ou bien même écrire une version personalisée de latex.doc.mk définissant cette variable.

Supposons que l'image représentant visuellement votre organisation soit dans ${HOME}/share/texmf/tex/organisation/visual.eps, afin que TeX examine le dossier contenant cette image, vous écrivez une affectation à TEXINPUTS dans votre Makefile, comme ceci :

DOC = galley.tex
TEXINPUTS = ${HOME}/share/texmf/organisation
.include "latex.doc.mk"

Exécuter make dans le dossier contenant le Makefile fera apparaître ceci dans votre terminal :

% make
make build
===> Multipass job for galley.dvi (aux)
env TEXINPUTS=".:${HOME}/share/texmf/organization:" latex galley.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
...

Examinons la liaison associée à TEXINPUTS par la commande env. Elle se distingue notamment de la spécification du Makefile par la présence d'un élément . au début et d'un élément vide à la fin. Ceux-ci indiquent à TeX de rechercher aussi les fichiers dans le dossier courant et dans les dossiers de l'installation TeX.

Si dans un cas particulier vous souhaitez avoir un contrôle total sur TEXINPUTS, il vous suffit de positionner USE_STRICT_TEXINPUTS à yes dans votre Makefile. S'il trouve ce positionnement, bsdowl n'ajoutera pas le point et l'élément vide à TEXINPUTS.

La prise en charge de METAPOST tient compte des valeurs de TEXINPUTS ET USE_STRICT_TEXINPUTS. Une variable analogue nommée MPINPUTS et sa compagne USE_STRICT_MPINPUTS permettent de configurer le chemin de recherche des fichiers par METAPOST.

Travailler avec des collections contenant un grand nombre de documents

Nous montrons comment utiliser le module bps.subdir.mk pour organiser une collection de documents. Pour les besoins de cet exemple, nous supposerons que vous préparez un journal électronique et souhaitez distribuer chaque article du journal comme un document individuel. Vous utilisez l'organisation suivante :

Vous avez préparé un répertoire contenant chaque numéro du journal, disons ${HOME}/journal.
Chaque numéro du journal est matérialisé par un sous-répertoire du dossier précédent.
Chaque article du journal est représenté par un sous-répertoire du dossier correspondant au numéro auquel il appartient.

Supposons que vous avez déjà préparé plusieurs articles, comme le suggère la commande suivante :

% find ./journal -type f
./journal/issue-2013-1/01-galdal/Makefile
./journal/issue-2013-1/01-galdal/article.tex
./journal/issue-2013-1/02-arathlor/Makefile
./journal/issue-2013-1/02-arathlor/article.tex
./journal/issue-2013-2/01-mirmilothor/Makefile
./journal/issue-2013-2/01-mirmilothor/article.tex
./journal/issue-2013-2/02-eoron/Makefile
./journal/issue-2013-2/02-eoron/article.tex
./journal/issue-2013-2/03-echalad/Makefile
./journal/issue-2013-2/03-echalad/article.tex

Les noms comme galdal, arathlor, etc. sont les noms des auteurs fictifs des articles non moins fictifs de votre journal. Chaque contribution est associée à un répertoire contenant le texte de l'article proprement dit article.tex et un Makefile semblable à ceux décrits plus haut dans cette dépêche et qui est utilisé pour préparer l'article correspondant.

Chacun de ces Makefile peut être aussi simple que:

DOC=    article.tex
.include "latex.doc.mk"

Pour coordonner la préparation de tous nos articles, il nous suffit d'écrire quelques Makefile supplémentaires :

./journal/Makefile
./journal/issue-2013-1/Makefile
./journal/issue-2013-2/Makefile
./journal/issue-2013-3/Makefile

Chaque Makefile contient essentiellement la liste des sous-répertoires que make doit explorer pour atteindre les cibles build, install ou clean. Ainsi le fichier ./journal/Makefile doit contenir :

SUBDIR=     issue-2013-1
SUBDIR+=    issue-2013-2
SUBDIR+=    issue-2013-3
.include "bps.subdir.mk"

Quant à lui, ./journal/issue-2013-1/Makefile doit contenir :

SUBDIR=     01-galdal
SUBDIR+=    02-arathlor
.include "bps.subdir.mk"

Les fichiers restants ./journal/issue-2013-2/Makefile et ./journal/issue-2013-3/Makefile doivent être préparés de façon similaire. Avec ces ajustements, les cibles all, build, clean, distclean, realclean et install sont déléguées aux Makefile trouvés dans les dossiers énumérés par SUBDIR.

La variable _SUBDIR_PREFIX peut être utilisée pour personnaliser le dossier d'installation pour chaque article. Changeons le Makefile associé à chaque article en :

DOC=    article.tex
DOCDIR= ${HOME}/publish/journal${_SUBDIR_PREFIX}
.include "latex.doc.mk"

Avec ce réglage, le document ./journal/issue-2013-1/01-galdal/article.dvi sera installé dans ${HOME}/publish/journal/issue-2013-1/01-galdal/article.dvi et ainsi de suite. Il est possible d'ajuster ceci pour utiliser un police de nommage complètement arbitraire pour l'installation des produits.

Contribuer

Le but de bsdowl est de fournir un système de déploiement de logiciel portable pour les systèmes UNIX modernes. Il se distingue d'autres approches par l'utilisation de simples fichiers Makefile et d'un programme standard : BSD Make. L'utilisateur de bsdowl écrit donc des fichiers Makefile, il n'est pas utile d'apprendre un énième langage de script pour écrire une spécification de compilation.

Pour la version 3.0 en préparation, je projette de réorganiser grandement le logiciel. Les projets sont :

Mise en avant des notions de module et de produit, pour se rapprocher du schéma d'organisation des projets dans les grands IDE classiques.
Concilier le point précédent avec une approche non bureaucratique pour les petits projets.
Utiliser de façon systématique un mode de développement axé sur les tests.

Si vous êtes intéressé(e) par bsdowl vous pouvez :

témoigner de votre intérêt en lui ajoutant une petite étoile dans GitHub ;
rapporter vos succès et vos infortunes, je suis notamment très intéressé par la préparation d'une liste de compatibilité.
contribuer des programmes de type hello-world ou de plus complexes pour m'aider à écrire des tests pour les langages que vous aimeriez voir pris en charge.

Aller plus loin

BSD Owl Scripts v2.2.1 (109 clics)
Producing LaTeX documents (72 clics)
Port pour MacPorts (19 clics)
Port pour FreeBSD (non officiel) (22 clics)
Paquet Debian Jessie (non officiel) (21 clics)

# Remerciements

Posté par Michaël (site web personnel) le 31 octobre 2014 à 01:20. Évalué à 4.

Merci à BAud, palm123, Snark et Benoît Sibaud pour leur aide et leur relecture!
# GNU Make

Posté par Egide Dey le 31 octobre 2014 à 09:52. Évalué à 3.

Cela semble être de la vraie balounette en barre !!!

Est-ce que quelqu’un connait quelque chose de similaire pour GNU Make ?

J'ai fait une tentative d'installation sur mon Arch. Cela fonctionne à merveille. Mai sje ne me vois pas demander à tous mes collègues de le faire à la main…

Un grand merci pour cet article!
- [^] # Re: GNU Make
  
  Posté par Michaël (site web personnel) le 31 octobre 2014 à 11:18. Évalué à 5. Dernière modification le 31 octobre 2014 à 11:23.
  Qu'est-ce que tu veux installer à la main? Il y a un package bmake dans arch Linux et tu peux donner à tes collègues un petit script d'installation du style
```
mkdir install-bsdowl
wget https://github.com/michipili/bsdowl/releases/download/v2.2.1/bsdowl-2.2.1.tar.xz
tar tf bsdowl-2.2.1.tar.xz
cd bsdowl-2.2.1
./configure --prefix=/usr/local
bmake -r all
bmake -r install
```
  à éxécuter en root. Si tu es motivé par l'écriture d'un paquet pour Arch, cela devrait être assez facile — en survolant le guide j'ai l'impression qu'il s'agit de quelque chose de pas très bureaucratique.
  
  Merci pour ton enthousiasme! Si tu as des problèmes, n'hésite pas à en parler ici ou sur l'issue tracker du projet!
  
  PS: GNU Make n'est vraiment pas super, à mon sens.
  - [^] # Re: GNU Make
    
    Posté par Egide Dey le 03 novembre 2014 à 14:09. Évalué à 0.
    
    Tout cuit et presque tout mâché pour tomber dans le gosier…
    
    Un grand merci!!!
    
    Je le fais ce soir en rentrant.
    - [^] # Re: GNU Make
      
      Posté par Michaël (site web personnel) le 03 novembre 2014 à 14:32. Évalué à 2.
      
      Si tu as un comptes GitHub, n'hésite pas à marquer le projet, comme ça tu seras au courant des nouvelles versions.
# Mais non, il ne faut pas un makefile pour gérer du latex !

Posté par boubou (site web personnel) le 31 octobre 2014 à 13:52. Évalué à 6.

C'est marrant comme cette idée de faire des makefiles pour compiler du latex reste ancrée dans les esprits… Et pourtant, ça ne marche pas. Je n'ai rien contre BSD Owl, juste pour être clair : ça ne marche pas non plus avec gnu Make. Qu'est-ce qui ne marche pas ?
1. la gestion des dépendances qui est manuelle dans ces solutions : on est en 2014 !
2. le choix du nombre de passes qui est aussi manuel alors qu'il doit être adaptatif en latex (index, biblio, packages tordus, etc.)

Bref, il existe depuis longtemps une solution qui fonctionne parfaitement : latexmk. Et contrairement à ce que son nom pourrait laisser croire, c'est un programme spécifique (en perl) pas un machin basé sur un make généraliste. Il gère les dépendances automatiquement (rapport à être en 2014, hein) en utilisant des hashs pour ne pas recompiler après un simple touch, détermine le nombre de passes nécessaires automatiquement, et est configurable dans tous les sens pour s'adapter à la complexité d'un workflow latex.

Je ne dirai pas ce que je pense vraiment de l'horodatage pour les versions, histoire de rester poli. Disons simplement qu'on ne fait généralement pas du latex pour des documents jetables. Alors écrire sa thèse sans utiliser un gestionnaire version, c'est tellement con à pleurer qu'on se demande comment le contenu pourrait être intéressant. Une des bonnes solutions est bien sûr git et gitinfo.
- [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
  
  Posté par Michaël (site web personnel) le 31 octobre 2014 à 14:46. Évalué à 4.
  C'est marrant comme cette idée de faire des makefiles pour compiler du latex reste ancrée dans les esprits… Et pourtant, ça ne marche pas.
  
  Ça marche très bien au contraire.
  1. la gestion des dépendances qui est manuelle dans ces solutions : on est en 2014 !
  Ce n'est pas une fatalité! Dans BSD Make il y a un mode meta qui surveille les processus fils pour déterminer la vraie liste de dépendances (tous les fichiers lus). C'est un sujet avancé et avec lequel je n'ai pas encore expérimenté mais c'est prévu pour la version 3.0 de BSD Owl.
  1. le choix du nombre de passes qui est aussi manuel alors qu'il doit être adaptatif en latex (index, biblio, packages tordus, etc.)
  Dans BSD Owl, c'est ajustable. Chaque passe a un nom, et la variable MULTIPASS énumère les passes à faire:
```
MULTIPASS= aux ref final
```
  Si ton package nécessite plus de passes, il suffit d'éditer cette variable dans le Makefile:
```
MULTIPASS= aux ref extrapass final
```
  Les noms des passes sont écrits dans les messages mais n'ont pas d'autre fonction.
  
  Bref, il existe depuis longtemps une solution qui fonctionne parfaitement : latexmk. Et contrairement à ce que son nom pourrait laisser croire, c'est un programme spécifique (en perl) pas un machin basé sur un make généraliste. Il gère les dépendances automatiquement (rapport à être en 2014, hein) en utilisant des hashs pour ne pas recompiler après un simple touch, détermine le nombre de passes nécessaires automatiquement, et est configurable dans tous les sens pour s'adapter à la complexité d'un workflow latex.
  
  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?
  
  Ceci mis à part BSD Owl est un système de build généraliste qui ne se limite pas du tout aux documents LaTeX. Pour le monde LaTeX on peut aussi s'en servir pour écrire et installer des classes de documents LaTeX avec noewb (un outil de programmation lettrée). On peut aussi s'en servir pour compiler et installer des tas de choses.
  
  Je vis aussi en 2014 et je vois qu'aucun des mille-et-un systèmes de build vachement meilleurs que make ne l'a détrôné. Mon analyse est que pour être vraiment généraliste un système de build doit permettre facilement d'accéder au shell et à ce niveau là, impossible d'être plus fort que make. Ensuite make est utilisé pour le build de systèmes d'exploitation entiers (au moins les BSD) ce qui démontre que le programme est largement utilisable en milieu industriel si on peut dire. Ce qui manque à make est une bilbiothèque de Makefiles portable et flexible, problème que je souhaite résoudre avec BSD Owl.
  
  Je ne dirai pas ce que je pense vraiment de l'horodatage pour les versions, histoire de rester poli.
  
  Bon passons, …
  
  Disons simplement qu'on ne fait généralement pas du latex pour des documents jetables. Alors écrire sa thèse sans utiliser un gestionnaire version, c'est tellement con à pleurer qu'on se demande comment le contenu pourrait être intéressant. Une des bonnes solutions est bien sûr git et gitinfo.
  
  Apparemment tu n'as pas lu le paragraphe Brouillons et traitements multiples.
  
  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.
  
  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.
  - [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
    
    Posté par boubou (site web personnel) le 31 octobre 2014 à 15:25. Évalué à 4.
    
    Ça marche très bien au contraire.
    
    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 Michaël (site web personnel) le 31 octobre 2014 à 16:13. Évalué à 3.
      Je ne suis pas certain de bien comprendre la question. Je soupçonne que tu demandes comment intégrer latexmk dans un makefile.
      
      Pour reprendre la conversation, je propose un outil qui résoud un problème, tu dis que cet outil n'a aucun intérêt parceque latexmk fait déjà tout en mieux… C'est donc normal que je te demande d'expliquer comment traiter avec l'outil que tu proposes, les problèmes que je résous avec le mien.
      
      Au final ce pourrait peut-être intéressant d'utiliser latexmk dans bsdowl mais c'est assez loin de ton discours. En fait non, mais tu sais dire à la fois
      
      C'est marrant comme cette idée de faire des makefiles pour compiler du latex reste ancrée dans les esprits… Et pourtant, ça ne marche pas.
      
      et
      
      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).
      
      Nous sommes d'accord, mais en quoi ça t'empêche d'utiliser localement celui que tu veux ?
      
      Ça ne m'en empêche pas et c'est ce que je fais. Pour mes collaborateurs, c'est plus intéressant d'avoir une liste de fichiers
      
      article-2014-01-07.pdf … article-2014-06-23.pdf
      
      que
      
      article-rf5gbda.pdf … article-qpr3rd1.pdf
      
      Une date est une information simple que tout le monde comprend.
      - [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 16:29. Évalué à 1.
        
        Je ne sais pas quel problème tu prétends résoudre avec ton outil. En revanche, le problème que tu sembles décrire est celui de la recompilation automatique d'un fichier latex quand cela doit être fait en raison d'une modification de quelque chose (sources latex, images, etc.). Or, ton outil ne résout pas ce problème parce qu'il faut écrire les dépendances la main et parce qu'il ne peut pas déterminer automatiquement le nombre de passes à faire. Et je soupçonne que cette tâche est en fait impossible à réaliser efficacement avec un outil de build généraliste (encore une fois, je n'en suis pas certain, c'est juste le fruit de 20 ans d'expérience).
        
        En revanche, et je ne vois là aucune contradiction, il parfaitement possible et utile d'intégrer un outil qui résout bien ce problème dans un makefile. D'ailleurs, latexmk produit un fichier de dépendances qui peut être récupéré dans le makefile (moyennant une transformation) pour gérer partiellement la tâche en question au niveau de l'outil généraliste (le nombre de passes étant toujours du ressort de latexmk).
        
        Donc, je récapitule, non, on ne peut pas compiler efficacement du latex en gérant ça avec un outil de make généraliste, oui, il existe un outil spécifique qui fait ça très bien et qui est intégrable dans un workflow plus complexe.
        
        Concernant les dates, la confusion entre instant de compilation et instant d'écriture est consternante. Et c'est bien tout l'intérêt de gitinfo2 (ou des solutions comparables pour d'autres gestionnaires de version, chacun ses vices) de ne pas faire cette confusion. Et bien sûr, on peut intégrer ce qu'on veut dans le nom du pdf avec un makefile bien construit.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par barmic le 31 octobre 2014 à 16:34. Évalué à 3.
        
        il existe un outil spécifique qui fait ça très bien et qui est intégrable dans un workflow plus complexe.
        
        et
        
        Au final ce pourrait peut-être intéressant d'utiliser latexmk dans bsdowl mais c'est assez loin de ton discours.
        
        Encore un petit effort et vous allez tomber d'accord.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 31 octobre 2014 à 16:57. Évalué à 2.
        
        Donc, je récapitule, non, on ne peut pas compiler efficacement du latex en gérant ça avec un outil de make généraliste, oui, il existe un outil spécifique qui fait ça très bien et qui est intégrable dans un workflow plus complexe.
        
        Et qu'est-ce qui t'empêche d'écrire ça dans ton premier commentaire? La partie “workflow plus complexe” n'est pas assez mise en avant dans la dépêche?
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 17:16. Évalué à 3.
        
        Parce que ta dépêche, intéressante au demeurant, prétend qu'on peut préparer des documents latex avec ton outil, ce qui est faux. Même pour des documents se contentant d'un format classique avec biblio, ton système ne peut pas déterminer à chaque fois et automatiquement le bon nombre de passes (j'ai l'impression de me répéter), sans parler des dépendances. Et c'est énervant car quand on cherche sur internet, on trouve tout un tas de pseudo-solutions comme la tienne qui ne fonctionnent pas. Trouver latexmk s'avère presque difficile. Il m'a donc semblé important de rétablir la vérité (ouai, rien que ça). Et si j'ai précisé que bmake etc. ne m'intéressait pas, c'est pour insister sur le fait que je ne critique ni le choix de l'outil, ni le principe de la bibliothèque de makefile, ni rien de tout ça. Simplement l'exemple du latex est mauvais et correspond à une mauvaise connaissance (ou une vision naïve) des problèmes de compilation associés. Ce sont certainement des limitations de TeX, mais on n'y peut pas grand chose pour l'instant, excepter utiliser un outil adapté (et donc pas un make généraliste !).
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 31 octobre 2014 à 17:25. Évalué à 1.
        
        Parce que ta dépêche, intéressante au demeurant, prétend qu'on peut préparer des documents latex avec ton outil, ce qui est faux. Même pour des documents se contentant d'un format classique avec biblio, ton système ne peut pas déterminer à chaque fois et automatiquement le bon nombre de passes (j'ai l'impression de me répéter), sans parler des dépendances. Et c'est énervant car quand on cherche sur internet, on trouve tout un tas de pseudo-solutions comme la tienne qui ne fonctionnent pas.
        
        Tu as des exemples concrets de documents qui sont mis en défaut par une approche naïve? Ou une méthode pour les produire?
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 17:40. Évalué à 1.
        
        Tu as des exemples concrets de documents qui sont mis en défaut par une approche naïve? Ou une méthode pour les produire?
        
        N'importe quel document avec une biblio. Si tu modifies le .bib, il faut en général une seule recompilation (après un bibtex/biber bien senti), sauf si la biblio devient plus longue (parce que tu as précisé la référence biblio et qu'elle prend maintenant plus de place). Dans ce deuxième cas, ça peut décaler ce qui vient après la biblio (index, annexe, etc.) d'où la nécessité d'au moins une autre passe pour mettre à jour la table des matières (s'il y en a une). C'est déjà compliqué. Mais si tu modifies le latex lui même, ça peut ou non modifier ce que tu cites, ce qui demande alors au moins une nouvelle compilation pour refaire la biblio, après avoir appelé bibtex. Et hop, retour au problème éventuel de table des matières. C'est tellement chiant qu'il faut parser la sortie du latex pour s'y retrouver.
        
        En ensuite, si tu utilises biblatex et biber (ce qu'il faut faire de nos jours), ça devient assez folklorique. Mon cv inclus ma liste de publications gérée par biblatex. Le nombre de publications par type, en page 2, est calculé automatiquement par biber. Parfois, ça prend 4 passes de compilations, parfois une seule. Je t'avoue que les raisons profondes me restent assez mystérieuses…
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 31 octobre 2014 à 18:11. Évalué à 1.
        
        N'importe quel document avec une biblio. Si tu modifies le .bib, il faut en général une seule recompilation (après un bibtex/biber bien senti) […]
        
        Mon approche est plutôt de ne compiler q'une seule fois le document pendant sa période de mise au point puis de le compiler un nombre suffisant de fois lorsque le document est finalisé. Faire le nombre minimum de compilations ne fait pas partie de mes objectifs.
        
        Mon cv inclus ma liste de […] Je t'avoue que les raisons profondes me restent assez mystérieuses…
        
        Je voulais parler d'un exemple avec des sources, que je puisse utiliser. Je ne vois pas pourquoi ce nombre de compilation devrait être aléatoire. On peut obtenir un document équivalent en générant la partie dynamique dans un fichier dédié, donc du point de vue de LaTeX, c'est une source comme les autres.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 18:34. Évalué à 1.
        
        Mon approche est plutôt de ne compiler q'une seule fois le document pendant sa période de mise au point puis de le compiler un nombre suffisant de fois lorsque le document est finalisé. Faire le nombre minimum de compilations ne fait pas partie de mes objectifs.
        
        C'est dangereux. Un de mes thésards a un jour soumis un article mal compilé ([?] pour les références) avec de genre de méthode. Et j'ai régulièrement des articles à lire qui présentent des bugs de ce genre. Je ne vois pas l'intérêt d'un makefile si on ne fait pas les choses proprement, mais bon, chacun son truc.
        
        Je voulais parler d'un exemple avec des sources, que je puisse utiliser. Je ne vois pas pourquoi ce nombre de compilation devrait être aléatoire. On peut obtenir un document équivalent en générant la partie dynamique dans un fichier dédié, donc du point de vue de LaTeX, c'est une source comme les autres.
        
        Certes, mais l'amélioration des outils (comme biber/biblatex qui remplacent bibtex) engendre plus d'aspects dynamiques de façon naturelle. De plus, le nombre de compilations n'est bien sûr pas aléatoire, mais il dépend de la nature des modifications effectuées dans les différentes sources qui concourent à produire le document final. Évidemment, si tu ne veux pas obtenir le vrai document final à chaque instant (chacun son truc, encore une fois), alors un makefile est suffisant mais à mon avis sans intérêt : pourquoi taper make plutôt que (pdf)latex ? La logique m'échappe, sauf dans un workflow complexe et là, la gestion manuelle des dépendances est tellement pénible que je ne vois pas non plus l'intérêt de gérer la compilation latex elle-même par le makefile.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 31 octobre 2014 à 18:52. Évalué à 3.
        
        C'est dangereux. Un de mes thésards a un jour soumis un article mal compilé ([?] pour les références) avec de genre de méthode.
        
        Je ne vois pas le rapport avec “compiler plus que nécessaire”. Au contraire ici, il n'a pas assez compilé!
        
        Pour ce qui est de bsdowl les messages de Warning ou Error LaTeX sur les références non définies est transformé en erreur de compilation par bsdowl et une liste récapitulative de tous les Warnings et de tous les Erros est affichée.
        
        Pour la soumission, d'article c'est un peu sa faute s'il ne vérifie pas ce qu'il envoie non? Même avec un système réputé fiable il faut vérifier ce qu'on envoie quand c'est important. Donc ici, c'est une erreur humaine, avant tout.
        
        Évidemment, si tu ne veux pas obtenir le vrai document final à chaque instant (chacun son truc, encore une fois), alors un makefile est suffisant mais à mon avis sans intérêt : pourquoi taper make plutôt que (pdf)latex ? La logique m'échappe, sauf dans un workflow complexe et là, la gestion manuelle des dépendances est tellement pénible que je ne vois pas non plus l'intérêt de gérer la compilation latex elle-même par le makefile.
        
        C'est justement (pour la deuxième fois) les “Workflow complexes” qui sont mis en avant par la dépêche, et ce que tu dis est écrit noir sur blanc dans la dépêche (par moi):
        
        La préparation d'un document simple avec LaTeX est en elle-même particulièrement simple, l'utilisation de bsdowl pourrait donc sembler une complication inutile. Cependant, même dans ce cas, l'utilisation de bsdowl rend d'appréciables services, comme l'installation et l'horodatage des fichiers produits.
        
        Néanmoins, la partie vraiment intéressante se situe dans la partie avancée.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 19:04. Évalué à 2.
        
        Je ne vois pas le rapport avec “compiler plus que nécessaire”. Au contraire ici, il n'a pas assez compilé!
        
        Tu dis que tu compiles une seule fois pendant l'écriture et le bon nombre (ou trop) en production. C'est une mauvaise idée, ça engendre notamment le problème que j'évoque. C'est un cas particulier de l'erreur classique qui consiste à distribuer le code de test au lieu du code de production.
        
        Pour ce qui est de bsdowl les messages de Warning ou Error LaTeX sur les références non définies est transformé en erreur de compilation par bsdowl et une liste récapitulative de tous les Warnings et de tous les Erros est affichée.
        
        Certes, et personne ne les regarde ;-)
        
        Pour la soumission, d'article c'est un peu sa faute s'il ne vérifie pas ce qu'il envoie non? Même avec un système réputé fiable il faut vérifier ce qu'on envoie quand c'est important. Donc ici, c'est une erreur humaine, avant tout.
        
        Et l'un des buts d'un outil automatique bien fait est de limiter ce genre d'erreur humaine, notamment quand on soumet en pleine nuit pour une conf prestigieuse dont la deadline est en pacific time.
        
        C'est justement (pour la deuxième fois) les “Workflow complexes” qui sont mis en avant par la dépêche, et ce que tu dis est écrit noir sur blanc dans la dépêche (par moi):
        
        Dans un workflow complexe, la gestion des dépendances manuelles est une bonne façon de se planter, on tourne en rond.
        
        Il existe un outil qui gère parfaitement les dépendances et le nombre de passes en latex. Tu peux l'intégrer dans ton machin, tu devrais être content. Et non, tu préfères défendre une solution qui ne marche pas toujours. C'est comme l'horodatage à la compilation, c'est une mauvaise idée, ça confond date de compilation et date de production et ça rend donc difficile l'ajustement entre les versions. En plus, ça te permet d'horodater une version qui n'existe pas vraiment dans ton gestionnaire de version et donc de te tirer dans le pied.
        
        Je te laisse t'amuser, je retourne écrire un article et le compiler avec latexmk.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 31 octobre 2014 à 19:18. Évalué à 2.
        
        Tu es vraiment hallucinant d'arrogance! C'est trop drôle!
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 19:35. Évalué à 0.
        
        Tu es vraiment hallucinant d'arrogance! C'est trop drôle!
        
        Je remarque que tu ne réponds toujours rien sur la confusion entre date de compilation et date d'écriture (après des pirouettes du type « ah ouai bibtex, mais moi, tu vois, je ne compile qu'une fois sauf à la fin ») mais que tu préfères m'insulter. Chacun son truc.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 31 octobre 2014 à 19:45. Évalué à 0.
        
        mais que tu préfères m'insulter. Chacun son truc.
        
        Ce n'est pas une insulte, c'est juste de l'information, Mr. Schocked.
        
        Je remarque que tu ne réponds toujours rien sur la confusion entre date de compilation et date d'écriture (après des pirouettes du type « ah ouai bibtex, mais moi, tu vois, je ne compile qu'une fois sauf à la fin »)
        
        https://linuxfr.org/news/preparation-de-documents-latex-avec-bsd-owl#comment-1570760
        
        Je remarque que tu ne réponds toujours rien à plein de points, que tu ne donnes pas d'exemples concrêts de documents problématiques, avec des sources, etc.
        
        J'en reste là, je ne vois plus d'intérêt de continuer de discuter avec toi.
    - [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
      
      Posté par Michaël (site web personnel) le 31 octobre 2014 à 16:20. Évalué à 0.
      
      (je me tamponne, pour être honnête)
      
      Au fait, merci pour cette précision vachement utile!
    - [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
      
      Posté par barmic le 31 octobre 2014 à 16:32. Évalué à 4.
      
      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).
      
      Ouai donc tu es entrain de dire qu'utiliser *make c'est mal, mais qu'en fait toi tu t'en sert et tu préfère utiliser latexmk pour pallier aux faiblesses du compilateur latex.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 16:48. Évalué à 1.
        
        Ouai donc tu es entrain de dire qu'utiliser *make c'est mal, mais qu'en fait toi tu t'en sert et tu préfère utiliser latexmk pour pallier aux faiblesses du compilateur latex.
        
        Non, je dis simplement qu'on ne peut pas gérer les passes de latex par un makefile, pas que c'est mal.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par barmic le 31 octobre 2014 à 17:22. Évalué à 5.
        
        Ce que je veux dire c'est que tu es surtout à un autre niveau. Tu utilise latexmk comme un wrapper de ton compilateur. bsd owl fait plus de la gestion de projet. C'est complémentaire.
        
        Sincèrement tu aurais moins l'impression de te répéter si tu évitait de commencer tes intervention en disant que l'auteur qui est devant toi fait de la merde et en étant dans une approche plus constructive.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 17:30. Évalué à 1.
        
        Sincèrement tu aurais moins l'impression de te répéter si tu évitait de commencer tes intervention en disant que l'auteur qui est devant toi fait de la merde et en étant dans une approche plus constructive.
        
        J'ai dit que ça ne marchait pas, c'est vrai. J'ai ensuite dit du mal de l'horodatage et je maintiens qu'il est consternant de confondre date de compilation et date d'écriture.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par anaseto le 31 octobre 2014 à 18:21. Évalué à 4.
        
        J'ai dit que ça ne marchait pas, c'est vrai.
        
        Je te trouve quand même un peu catégorique. Je ne dis pas que latexmk n'est pas bien, au contraire, je trouve ça intéressant, mais un système plus naïf marche quand même dans beaucoup de cas. Pour dire, ma façon de faire est encore plus naïve (simples makefiles portables écrits à la main avec un peu de m4 pour pas trop me répéter) et je n'ai pas l'impression de passer mon temps avec des problèmes de build.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 31 octobre 2014 à 18:36. Évalué à 1.
        
        un système plus naïf marche quand même dans beaucoup de cas
        
        Oui, mais l'intérêt d'un makefile, c'est justement de gérer les cas évolués, sinon un (pdf/lua/whatever)latex est largement suffisant. Et surtout, il y a un logiciel libre qui fonctionne et qui est maintenu, quel intérêt de faire moins bien ?
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par barmic le 01 novembre 2014 à 02:03. Évalué à 4.
        
        J'ai dit que ça ne marchait pas, c'est vrai.
        
        C'est pas le fait de le répéter qui va rendre la chose réelle. Tes arguments disent :
        
        que ça peut potentiellement générer des erreurs parce qu'il y a une partie manuelle
        
        qu'il y aurait des cas (qui restent imaginaires) où ça ne marcherait pas
        
        il y a des cas où c'est sous-optimal (mais ça ne veux pas dire que ça ne marche pas)
        
        De l'autre coté l'auteur s'en sert depuis pas mal de temps et il a, je crois, quelques utilisateurs régulier. Donc un affirmation aussi péremptoire sans plus d'argument n'a aucune valeur.
        
        Tu sais, que tu peut défendre l'idée que latexmk est mieux sans dire que le reste c'est de la merde ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 01 novembre 2014 à 15:40. Évalué à 4.
        
        Sommaire
        
        Qu'est que fonctionner dans le contexte ?
        
        Pas d'automaticité
        
        Optimalité ou correction, il faut choisir
        
        L'horodatage est une mauvaise idée
        
        Conclusion : ça ne marche pas bien
        
        Tu sais, que tu peut défendre l'idée que latexmk est mieux sans dire que le reste c'est de la merde ?
        
        Je me permets de te faire remarquer que je n'ai jamais écrit ça. Tu ne fais peut être pas la différence « truc ne marche pas » et « truc est de la merde », moi si. Mais passons.
        
        Qu'est que fonctionner dans le contexte ?
        
        Je reprends donc depuis le début. Ma compréhension de la dépêche est que l'auteur propose un outil qui aurait deux fonctions. La première est d'assurer la production d'un pdf/ps à partir (notamment) d'un fichier latex maître et de toutes ses dépendances. La deuxième est de faciliter l'interaction avec des personnes qui n'utilisent pas un gestionnaire de version (ou pas le même que l'auteur) grâce à un mécanisme d'horodatage des fichiers compilés qui permettrait de retrouver les sources utilisées pour produire la version partagée. J'affirme que la solution proposée ne fonctionne pas dans des cas classiques et ne lutte pas contre les erreurs humaines classiques (notamment en tournant le dos aux bonnes pratiques en développement logiciel). Mes arguments sont simples et classiques pour quelqu'un qui connaît bien latex. Ce n'est probablement pas le cas de l'auteur qui me présente ensuite comme arrogant quand je lui dis. (mais bon, on s'en fout, l'important c'est que ça ne fonctionne pas).
        
        Je vais d'abord parler de la production automatique du document pdf (pour simplifier, je dirai juste pdf, mais ça pourrait être ps, voire d'autres choses). Mais pour ça, je dois préciser ce que je veux dire par production automatique d'un pdf. Mon point de vue est que je dois pouvoir taper quelque chose comme make toto.pdf et obtenir totalement automatiquement le bon fichier toto.pdf à la fin de l'exécution de la commande. J'insiste sur le fait que ça doit être automatique à chaque fois, quelles que soient mes modifications sur l'ensemble des sources. Et j'insiste sur le fait que ça doit être le bon fichier, pas un machin qui ne tiendrait pas compte de certaines de mes modifications. Et je veux en plus que ça soit fait de façon optimale en temps de calcul. Car latex reste lent : je pense qu'on tourne autour de 50 pages à la seconde sur un PC classique. Si on doit faire 3 ou 4 passes sur une thèse de 200 pages, ça fait 15 secondes, c'est quand même chiant pour juger les effets de la modification d'un paramètre de présentation, par exemple. Et c'est sans packages évolués comme tikz et ses amis avec lesquels on peut descendre à beaucoup moins que 50 pages par seconde.
        
        Si j'insiste sur ces trois aspects, automaticité, correction et efficacité, c'est que je sais par expérience (plus de 20 ans de latex) qu'un compromis engendre des problèmes. Si le processus n'est pas correct, on peut être amené à diffuser un document incomplet ou incohérent. Si le processus est lent (trop de passes), on va contourner la lenteur en réduisant artificiellement le nombre de passes, ce qui rendra le document incorrect (c'est ce que préconise explicitement l'auteur, ce qui un très mauvais choix dont je constate les effets délétères très régulièrement dans mon travail d'édition scientifique). Enfin, si ce n'est pas automatique, on oubliera un jour d'ajouter des dépendances ou d'en enlever, entraînant des problèmes de correction et/ou d'efficacité (trop de compilation ou pas assez). Si les systèmes de production actuels sont si complexes c'est notamment par ce qu'ils visent exactement ces trois aspects avec en plus la reproductibilité.
        
        Pas d'automaticité
        
        Or, la solution proposée n'est pas automatique : en particulier, elle ne gère pas automatiquement les dépendances. L'auteur repousse ça au futur alors que des solutions existent aujourd'hui (comme latexmk ou d'autres comme arara ou Rubber). Au delà du problème classique évident que ça pose dans tout contexte de dépendances entre objets, il y a des cas un peu spécifiques à latex. Prenons un fichier maître comme suit monlatex.tex :
        
        \documentclass{article} \begin{document} \include{bla1} \include{bla2} \end{document}
        
        et deux fichiers inclus bla1.tex :
        
        \section{Bla 1} Mon bla 1.
        
        et bla2.tex :
        
        \section{Bla 2} Mon bla 2.
        
        Avec une gestion de dépendances (automatique ou non), monlatex.pdf dépend évidemment de monlatex.tex, bla1.tex et bla2.tex. Maintenant, imaginons que les deux parties soient volumineuses et donc longues à compiler. Il est classique dans cette situation d'utiliser la commande latex \includeonly qui permet de restreindre la compilation en n'incluant que les parties qu'on souhaite (c'est un peu plus subtil que cela, mais peu importe). J'ajoute par exemple avant le \begin{document} l'instruction \includeonly{bla1} et je recompile (avec latexmk, bien sûr). Comme la mise à jour des dépendances est automatique, celle à bla2.tex est supprimée et aucune modification du fichier ne produit de mise à jour de monlatex.pdf. Au contraire, dès que j'enlève l'appel à \includeonly, la dépendance revient, ce qui est exactement ce qu'on veut. En particulier (et c'est la subtilité au dessus), les labels et autres objets du même type définis par bla2.tex qui étaient conservés et utilisés lors de la compilation réduite à l'inclusion de bla1.tex sont mis à jour automatiquement (donc avec le bon nombre de passes) si besoin est (notamment si bla2.tex a été modifié). Impossible d'avoir ce type de comportement avec la solution proposée.
        
        Optimalité ou correction, il faut choisir
        
        Passons maintenant à l'optimalité. Il faut savoir qu'en latex le nombre de passes nécessaires à l'obtention d'un document correct n'est pas borné à priori. Il existe en fait des documents qui ne sont pas compilables de façon stable. Par exemple (issu de stackexchange) :
        
        \documentclass{article} \pagenumbering{Roman} \begin{document} a\clearpage b\clearpage c\clearpage \begin{figure}[!t] \framebox(200,430){} \caption{a figure to take up space} \end{figure} Some interesting text about something in Section \ref{x}, which starts on page \pageref{x}. \section{zzz\label{x}} The text of an interesting section. \end{document}
        
        Au delà des cas pathologiques, il faut bien comprendre qu'il est impossible de savoir combien de passes seront nécessaires à obtenir un document correct en se basant seulement sur la liste des fichiers modifiés dans l'ensemble des dépendances. En effet, la nature des modifications induit des besoins différents au niveau des passes et des outils. Prenons un exemple simple. Je modifie monlatex.tex en
        
        \documentclass{article} \begin{document} \include{bla1} \include{bla2} \bibliographystyle{plain} \bibliography{mabib.bib} \end{document}
        
        et j'ajoute donc un fichier bibtex (tient une nouvelle dépendance à ajouter à la main… ou pas avec latexmk) :
        
        @Book{RobertBozo2014, author = {Bozo, Robert}, title = {Oui Oui fait du latex}, publisher = {Bozo Inc.}, year = 2014}
        
        Quand je lance latexmk, j'obtiens les passes suivantes :
        1) pdflatex monlatex.tex : détection de la nouvelle dépendance mabib.bib ;
        2) bibtex monlatex : bug car pas de citation, mais latexmk s'en fout, il connaît cette erreur et sait que ce n'est pas un vrai problème. Il découvre quand même le fichier monlatex.bbl (vide ou presque) qui devient une nouvelle dépendance (on sait jamais, je pourrai vouloir le modifier à la main) ;
        3) pdlfatex monlatex.tex : normal car le bbl a été produit et il faut l'intégrer.
        
        Que se passe-t-il maintenant si je modifie bla1.tex ? Tout dépend de la nature de la modification, chose que le système proposé par l'auteur ne peut pas détecter. Si mon nouveau bla1.tex est le suivant
        
        \section{Bla 1} Mon bla 1 modifié.
        
        alors une seule passe de pdflatex est suffisante (et c'est ce que fait latexmk, bien sûr). En revanche, si mon nouveau bla1.tex est
        
        \section{Bla 1} Mon bla 1 \cite{RobertBozo2014}.
        
        alors il faut trois passes : un pdflatex, un bibtex et un pdflatex.
        
        Et tout ça n'est qu'un exemple de base absolument standard (comme je le disais plus haut). Dès qu'on commence à utiliser des packages évolués, la situation se complique. On peut voir sur stackexchange des exemples de documents qui nécessitent n passes pour n arbitraire. C'est le cas par exemple de documents produits avec longtable.
        
        La solution proposée par l'auteur est de choisir à la main le nombre de passes. On peut donc choisir entre quelque chose d'inefficace (sachant que pdflatex+bibtex+pdflatex est en gros le minimum pour un document avec des citations, mais ça peut encore être incorrect s'il y a des modifications de la table des matières) ou quelque chose d'incorrect (pas assez de passes dans certains cas). Comme je l'ai dit en introduction, c'est inacceptable, d'autant qu'il existe des solutions qui fonctionnent parfaitement.
        
        En outre, l'auteur ne sait pas (apparemment) que les documents latex sont très dynamiques. Si j'utilise un style de citation qui inclut les noms d'auteurs dans les étiquettes, une modification du fichier bibtex peut entraîner plusieurs recompilations du latex car les étiquettes peuvent changer et donc entraîner des modifications de mise en page. L'exemple de mon cv donné plus haut montre aussi que certains compteurs peuvent être calculés par biber (le remplaçant de bibtex) en fonction du contenu des fichiers bibtex mais aussi en fonction des commandes dans le latex (en gros, biblatex permet la définition de collections dont la taille peut notamment être utilisée dans le latex lui même). Tout ça conduit à des compilations plus ou moins complexes.
        
        Bref, tout ça est connu et archiconnu et c'est pour ça qu'il existe pléthore d'outils de compilation spécifique à latex. On peut voir ça (à juste titre) comme une limitation de latex, mais ça ne change au rien au fait qu'il faut la gérer, ce qu'un système à la make ne peut pas faire simplement.
        
        L'horodatage est une mauvaise idée
        
        Terminons par cette idée d'horodatage. Le cas d'utilisation (partage de documents en dehors d'un gestionnaire de version) est tout à fait réaliste, mais la solution proposée est naïve (c'est globalement le cas de toute la dépêche, d'ailleurs). Elle repose sur la confusion entre instant de compilation et instant de production. Dois-je vraiment expliquer cela ? Si je compile mon latex maintenant et que j'obtiens monlatex-2014-11-01-15-16.pdf, est-ce que ça veut dire que c'est la version des sources du 1er novembre 2015 à 15h16 ? Bien sûr que non ! C'est le moment de la compilation, nom de dieu ! Et quand bien même je compilerais juste après avoir écrit quelque chose, rien ne garantit dans cette solution que je pourrai revenir à la version du 1er novembre 2015 à 15h16 car je ne sais pas si cette version existe dans mon gestionnaire de versions !
        
        Et donc, il ne faut pas faire comme ça. C'est tellement évident d'après toute l'histoire du développement logiciel qu'on se demande comment on peut avoir une telle idée (oui je sais je suis arrogant, c'est ça…). D'autant qu'il existe des solutions simples. D'abord, il faut intégrer dans le pdf lui-même de quoi retrouver la version des sources utilisée pour le produire dans le gestionnaire de version. C'est facile avec gitinfo2 et il y a d'autres packages pour d'autres gestionnaires de version. Ensuite, il faut prévoir un mode de release dans le makefile (ou sous forme d'un hook git, par exemple) qui ne fonctionne que sur une version vraiment existante dans le gestionnaire de version (donc qui refuse de produire le pdf s'il y a des modifications non commitées) et qui utilise dans le nom de fichier la date (et heure) de la version concernée. Encore une fois, ça ne pose pas de problème particulier. Notons que gitinfo2 ne donnera que des informations sur une version existante des sources et n'utilisera donc pas la date de la compilation mais bien celle de la version.
        
        Conclusion : ça ne marche pas bien
        
        Voilà, soyons finalement gentil avec l'auteur, sa solution ne marche pas bien. Elle boite pas mal. Il existe des solutions qui marchent très bien, elles. Elles existent depuis longtemps. Les personnes arrogantes comme moi le savent. Les personnes arrogantes comme l'auteur pensent probablement qu'elles n'ont pas besoin de regarder ce qui se fait pour compiler du latex et qu'elles sont suffisamment compétentes pour faire ça elles-mêmes. Chacun son arrogance.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par claudex le 01 novembre 2014 à 17:16. Évalué à 2.
        
        Voilà, soyons finalement gentil avec l'auteur, sa solution ne marche pas bien. Elle boite pas mal. Il existe des solutions qui marchent très bien, elles.
        
        En fait, tu es vraiment un grand prétentieux qui ne comprend pas le français. C'est triste de te voir attaquer comme cela quelqu'un qui propose son travail qui ne te nuit en rien.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par claudex le 01 novembre 2014 à 17:18. Évalué à 0.
        
        Ça a le mérite de conforter mon opinion sur la recherche.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 01 novembre 2014 à 17:39. Évalué à 3.
        
        Et en plus, je mange des chats.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 01 novembre 2014 à 17:41. Évalué à 5.
        
        C'est triste de te voir attaquer comme cela quelqu'un qui propose son travail qui ne te nuit en rien.
        
        La dernière année de ma thèse j'ai lu «Récoltes et Semailles» une autobiographie du mathématicien Alexandre Grothendieck. Il y fait un portrait du mathématicien successful typique de son époque: un aspirant champion du monde en poids et haltères, exhibitionniste, vouant par réflexe un mépris affiché à toutes les approches qui ne sont pas les siennes. Un portrait dont les traits dominants sont aux antipodes de la curiosité et de la générosité qui animent toute démarche scientifique sincère.
        
        Pour la petite histoire, la prise de conscience de l'existence de ce stéréotype et du fait qu'il en était lui-même devenu un parfait stéréotype l'ont amené à pratiquement renoncer à sa carrière prestigieuse pour se rapprocher de la générosité et de la curiosité qu'il avait délaissées pendant de nombreuses années, comme il le raconte dans son livre.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 01 novembre 2014 à 17:52. Évalué à 1.
        
        un aspirant champion du monde en poids et haltères, exhibitionniste, vouant par réflexe un mépris affiché à toutes les approches qui ne sont pas les siennes.
        
        Et est-ce qu'il mange des chats, le mathématicien en question ? Ça manque quand même, sinon.
        
        Pour la petite histoire, la prise de conscience de l'existence de ce stéréotype et du fait qu'il en était lui-même devenu un parfait stéréotype l'ont amené à pratiquement renoncer à sa carrière prestigieuse pour se rapprocher de la générosité et de la curiosité qu'il avait délaissées pendant de nombreuses années, comme il le raconte dans son livre.
        
        Et c'est sûrement par générosité qu'il refuse qu'on publie ses résultats et tout ce qu'il a fait depuis qu'il vit dans une grotte (ou presque).
        
        Et sinon, le rapport avec les makefiles ?
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par anaseto le 01 novembre 2014 à 18:32. Évalué à 8.
        
        Ce que j'ai retenu, c'est que latexmk se débrouille très bien pour faire le calcul de dépendances et du nombre de passes nécessaires pour compiler un document LaTeX. Du coup, BSD Owl pourrait simplifier et améliorer significativement cette partie en passant par latexmk (du moins comme dépendance optionnelle) pour son module pour LaTeX. D'autres choses (comme la possibilité de faire un "make install"), font que les deux outils peuvent devenir complémentaires pour le LaTeX.
        
        Je pense que si tu en étais resté purement aux points techniquement faibles du système que latexmk résout, ton message aurait été beaucoup mieux reçu ; il vaut mieux éviter les "on est en 2014" et ce genre de choses, qui ne sont pas très efficaces, et brouillent le message.
        
        Enfin, merci quand même de m'avoir fait découvrir latexmk, je pense que je vais l'utiliser à partir de maintenant.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 01 novembre 2014 à 18:51. Évalué à 2.
        
        Je pense que si tu en étais resté purement aux points techniquement faibles du système que latexmk résout, ton message aurait été beaucoup mieux reçu
        
        Absolument, son attitude m'ôte vraiment toute envie de discuter avec lui — d'autant que la discussion ne semble pas vraiment possible.
        
        Concernant le nombre de compilations, latexmk va procéder a 5 compilations, ou moins s'il s'aperçoit qu'aucune compilations supplémentaire n'est nécessaire. La stratégie de bsdowl consistant à faire un nombre prédéterminé de compilations n'est pas à des années-lumières. Et on attend toujours un exemple de document “de la vraie vie” (par exemple une référence sur arXiv.org) qui est bien compilé en 3 ou 4 passes mais mal compilé en 5 passes.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par boubou (site web personnel) le 01 novembre 2014 à 18:58. Évalué à -1.
        
        La stratégie de bsdowl consistant à faire un nombre prédéterminé de compilations n'est pas à des années-lumières.
        
        Je t'invite à relire mon message expliquant l'impact d'avoir trop de compilations en terme de perte de temps et donc de tentation pour les utilisateurs d'en faire moins, exactement comme tu le préconises plus haut (une seule compilation avant la phase « finale »).
        
        Et on attend toujours un exemple de document “de la vraie vie” (par exemple une référence sur arXiv.org) qui est bien compilé en 3 ou 4 passes mais mal compilé en 5 passes.
        
        Car bien sûr, j'ai dit que ça existait. J'ai toujours parlé de faire le nombre optimal, je n'ai jamais indiqué qu'il ne fallait pas en faire trop pour des raisons de correction. Le problème est l'efficacité.
        
        d'autant que la discussion ne semble pas vraiment possible.
        
        Certes, cf au dessus.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Sytoka Modon (site web personnel) le 02 novembre 2014 à 20:46. Évalué à 4.
        
        J'avais écrit il y a pas mal d'année un Makefile qui optimisait le nombre de passe via un grep de la sortie (LaTeX te dis ce qu'il est préférable de recompiler). En pratique, c'est assez chiant. Pourquoi ? Le plus souvent, tu recompiles pour voir ce que cela donne sur les quelques paragraphes que tu as travaillé, tu te fout alors des références bibliographiques ou autres. J'avais dans mes Makefile un simple target 'pdf' et j'avais remarqué que dans 99% des cas, je n'utilisais que celui-la.
        
        Pour ma part, je fais une simple compilation rapide, lorsque je retouche à la bibliographie, je fais alors un petit coup de 'make bib'. Au final (donc très rarement), un bon 'make pdfall' qui 'clean' tout, puis mouline un max bêtement ! Bref, pas optimum je l'accorde mais efficace pour mon usage et en terme CO2 ;-)
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 02 novembre 2014 à 22:09. Évalué à 2.
        
        Le plus souvent, tu recompiles pour voir ce que cela donne sur les quelques paragraphes que tu as travaillé, tu te fout alors des références bibliographiques ou autres. J'avais dans mes Makefile un simple target 'pdf' et j'avais remarqué que dans 99% des cas, je n'utilisais que celui-la.
        
        C'est aussi mon constat et la raison pour laquelle j'ai choisi cette approche dans BSD Owl.
        
        [^] # Re: Mais non, il ne faut pas un makefile pour gérer du latex !
        
        Posté par Michaël (site web personnel) le 01 novembre 2014 à 18:18. Évalué à 1.
        
        Le programme latexmk considère a priori qu'il ne faut pas plus de 5 passes pour compiler un document LaTeX non pathologique:
        
        $max_repeat [5] The maximum number of times latexmk will run latex/pdflatex before deciding that there may be an infinite loop and that it needs to bail out, rather than rerunning latex/pdflatex again to resolve cross-references, etc. The default value covers all normal cases.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

Sommaire

Préparer des documents avec LaTeX

Avertissement: travailler avec TeX ou LaTeX

Avertissement: BSD Make

Utilisation simple

La première fois

Installation ou publication

Choix du format de sortie

Brouillons et traitements multiples

Un document dans plusieurs fichiers

Fonctions avancées

Figures avec METAPOST

Bibliographie

Plusieurs documents dans le même dossier

Génération automatique d'une portion de document

Code source réparti dans plusieurs répertoires

Travailler avec des collections contenant un grand nombre de documents

Contribuer

Aller plus loin

Sommaire

Qu'est que fonctionner dans le contexte ?

Pas d'automaticité

Optimalité ou correction, il faut choisir

L'horodatage est une mauvaise idée

Conclusion : ça ne marche pas bien