Je ne connais ni rubber ni latexmk donc je ne peux pas trop comparer à ce que j'ai écrit.
Écrire des macros pour make c'est la même chose que de la programmation en shell à ceci près que la logique du traitement n'est pas exprimée par des procédure mais par des recettes et des dépendances. On explique seulement à make les étapes élémentaires de la construction et make se débrouille pour constuire un plan d'action.
Pour ta question précise, j'ai une réponse précise, en trois étapes:
On spécifie clairement le problème.
On résout le problème dans le shell.
On intègre le point 2 dans le workflow de make.
Voilà la spécification que je propose: je suppose que tu as une macro plopfizz qui prend en argument les paramètres de ton image et fait deux choses. Premièrement elle écrit ces paramètres dans un fichier id.plopfizz ou id caractérise l'appel. Deuxièmement elle regarde si l'image id.png résultat du traitement existe déjà pour éventuellement l'inclure dans le document. Ce n'est certainement pas exactement ta situation, mais probablement assez similaire.
On prépare une routine shell, disons process-plopfizz.sh qui lit un fichier id-plopfizz et prépare l'image id.png. La prépration d'un document ressemble donc à
$ pdflatex galley.tex
$ sh ./process-plopfizz.sh -o id1.png id1.plopfizz
$ sh ./process-plopfizz.sh -o id2.png id2.plopfizz
$ pdflatex galley.tex
Maintenant on peut intégrer dans le workflow de make. Pour cela, comme make se fie aux timestamp d'un fichier pour savoir s'il a été modifié, il faut être un peu sioux et améliorer la macro TeX plopfizz pour qu'elle lise le fichier id.plopfizz s'il existe et n'en écrive un nouveau que si les paramètres ont changé.
est l'incantation vaudou qui insère notre solution dans le workflow de make. Les déclarations suivantes sont des recettes make standard et les deux dernières lignes ajoutent les produits aux listes de fichiers à effacer, avec make clean où make distclean. La forme make distclean efface moins de fichiers que make clean. Ici les images sont conservées mais pas les fichiers intermédiaires plopfizz, ce qui facilite la préparation d'une archive qu'on envoie à son éditeur par exemple.
On voit bien que la préparation des images pourrait être améliorée en introduisant des règles génériques ou des variables, mais j'ai pensé qu'on pouvait dans un premier temps se contenter d'une solution "bébête" qui n'aie pas l'air artificiellement compliquée.
Bien-sûr c'est garanti sans test, mais c'est la route à suivre.
P.S.: Si tu prépares un use case ou bien une use story un peu plus précis, je peux te donner plus de détails! L'idéal serait quelque chose que je puisse incorporer au source dans le dossier test.
[^] # Re: Problématique
Posté par Michaël (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 4. Dernière modification le 08 janvier 2014 à 19:44.
Je ne connais ni
rubbernilatexmkdonc je ne peux pas trop comparer à ce que j'ai écrit.Écrire des macros pour
makec'est la même chose que de la programmation en shell à ceci près que la logique du traitement n'est pas exprimée par des procédure mais par des recettes et des dépendances. On explique seulement àmakeles étapes élémentaires de la construction etmakese débrouille pour constuire un plan d'action.Pour ta question précise, j'ai une réponse précise, en trois étapes:
make.Voilà la spécification que je propose: je suppose que tu as une macro
plopfizzqui prend en argument les paramètres de ton image et fait deux choses. Premièrement elle écrit ces paramètres dans un fichierid.plopfizzouidcaractérise l'appel. Deuxièmement elle regarde si l'imageid.pngrésultat du traitement existe déjà pour éventuellement l'inclure dans le document. Ce n'est certainement pas exactement ta situation, mais probablement assez similaire.On prépare une routine shell, disons
process-plopfizz.shqui lit un fichierid-plopfizzet prépare l'imageid.png. La prépration d'un document ressemble donc àMaintenant on peut intégrer dans le workflow de
make. Pour cela, commemakese fie auxtimestampd'un fichier pour savoir s'il a été modifié, il faut être un peu sioux et améliorer la macro TeXplopfizzpour qu'elle lise le fichierid.plopfizzs'il existe et n'en écrive un nouveau que si les paramètres ont changé.À la fin, le fichier
Makefileressemblerait àLa ligne
est l'incantation vaudou qui insère notre solution dans le workflow de
make. Les déclarations suivantes sont des recettesmakestandard et les deux dernières lignes ajoutent les produits aux listes de fichiers à effacer, avecmake cleanoùmake distclean. La formemake distcleanefface moins de fichiers quemake clean. Ici les images sont conservées mais pas les fichiers intermédiairesplopfizz, ce qui facilite la préparation d'une archive qu'on envoie à son éditeur par exemple.On voit bien que la préparation des images pourrait être améliorée en introduisant des règles génériques ou des variables, mais j'ai pensé qu'on pouvait dans un premier temps se contenter d'une solution "bébête" qui n'aie pas l'air artificiellement compliquée.
Bien-sûr c'est garanti sans test, mais c'est la route à suivre.
P.S.: Si tu prépares un
use caseou bien uneuse storyun peu plus précis, je peux te donner plus de détails! L'idéal serait quelque chose que je puisse incorporer au source dans le dossier test.