• [^] # Re: Problématique

    Posté par (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 3.

    Sommaire

    Merci pour ce message.

    Ta solution est intéressante, sauf qu'elle force à décrire dans le makefile la liste de toutes tes dépendances. Ma (courte) thèse contient actuellement plusieurs dizaines de dépendances générées et je n'ai pas envie de devoir les décrire une par une dans le makefile sachant que je le fais déjà dans le .tex.

    Use case simple

    J'ai besoin de convertir les .poulet en .tortue.

    dans latex:

    \includegraphics{hibou.tortue}
    

    Là latexmk (ou rubber) est capable d'appeler make pour toutes les dépendances, ainsi :

    $ make hibou.tortue
    

    Il y a une règle relativement simple qui dit que :

    %.tortue: %.hibou
     tortufy $*
    

    Use case avancé

    J'ai un programme qui prend en paramètre un nom de svg (source.svg) et la liste de calques à exporter (calque1 et calque2) et qui génère un .pdf.

    Dans mon latex:

    \includegraphics{source__calque1_calque2_layers.pdf}

    Le soucis c'est que on ne peut plus faire de règle makefile simple du genre :

    %1__%2_layers.pdf: %1.svg
     export_mon_svg --input 1ドル.svg --layers 2ドル --output 1ドル__2ドル_layers.pdf
    

    avec %1 et %2 des trucs génériques qui seront par la suite associés à 1ドル et 2ドル

    Ce cas reste encore un peu simple, car finalement il suffit d'écrire pour chaque fichier svg du répertoire la règle :

    fichier__%_layers.pdf: fichier.svg
     export_mon_svg --input fichier.svg --layers 2ドル --output fichier__2ドル_layers.pdf
    

    et on peut faire cela avec une macro make:

    define LAYER_template
    $(1)__%__layer.pdf: $(1).svg
     python2 scripts/layer.py $(1).svg $$* $(1)__$$*__layer.pdf
    endef
    SVG_LAYER_NAMES = $(shell hg manifest | grep .svg | sed 's/\.svg//')
    $(foreach p, $(SVG_LAYER_NAMES), \
     $(eval $(call LAYER_template,$(p))) \
    )
    

    (ici il me prend tous les .svg que mercurial connait, mais bon)

    Ça commence à faire mal ici (en gros, je suis le seul humain de tout ceux qui bossent sur ce projet (i.e, heureusement que c'est ma thèse) qui veut encore lire le makefile).

    Cas pathologique (90% de mes use cases)

    Je veux un fichier de sortie qui dépend d'un nombre de fichiers d'entrés indéterminé et de N paramètres. Dans mon latex je fais :

    \includegraphics{fichier1_fichier2_fichier3__param1_param2__uberrule.png}
    

    et dans mon makefile, et bien je ne sais pas ce que je fais. J'avais adopté une nouvelle solution, je sous-traitais à un script :

    %__uber.png: 
     mon_script $*
    

    qui génère la liste de dépendances qui sera évalué par make à la prochaine passe pour gérer correctement mon build.

    Et là je meurs.

    Solution actuelle

    Alors finalement je fais autrement. J'ai une fonction

    \includegraphisCommand{}
    

    Qui prend une commande.

    LaTeX ouvre un pipe et écrit cette commande et lit dans un pipe le nom du fichier à inclure.

    Un démon (en python, mais on s'en cogne) lit dans le pipe la commande à exécuter, et écrit le nom temporaire de sortie après exécution (en gérant bien évidement un cache pour ne pas reconstruire tout à chaque fois).

    Exemple :

    \includegraphicsCommand{svg('input.svg', ['calque1', 'calque2'])}
    

    Et dans mon code python, j'ai défini une fonction :

    def svg(input, layers):
     output_name = nom_unique('svg', input, layers) # genere un nom unique pour ce fichier de sorti, basé sur le nom et les arguments de la méthode
     if must_rebuild([output_name], [input]): # fonction générique qui regarde si il faut rebuilder
     # action pour builder
     return output_name
    

    Ainsi:

    a) chaque action de build est en fait une simple fonction python dans un fichier, fonction paramétrée comme bon me semble et appelée naturellement depuis mon .tex. Mon pire exemple c'est :

    \includegraphicsCommand{calcul_vecteurs_mouvements(resize((800, 600), rendu_video_blender(scene.blend, start_frame=0, end_frame=12, resolution=(800, 600), samplesPerPixels=12, materials=('red', 'blue'))))}
    

    b) Je m’embête plus à trouver des noms pour mes fichiers générés, j'ai une fonction de hash à la con qui fait cela, met tout dans /tmp et voila. En plus c'est sympa, le nom dépend des paramètres de la commande et pas de l'endroit ou elle est appelée dans le .tex. Ainsi si je décide de tester en changeant un paramètre, cela va compiler pendant 2 heures, et si je revient sur la version précédente, cela va reprendre l'ancien fichier déjà présent dans le cache.

    c) Toutes les dépendances sont mise à jour lors de la passe sur le .tex et dirigées par le contenu du .tex. Ainsi tout est bien synchronisé.

    d) Je peux intégrer des "plugins" dans mon outil de rendu. Par exemple, à tout moment, je peux dire que les résultats images qui sortent sont downscalés, ainsi mon pdf se construit plus vite (cela permet d'avoir le bon visuel dans le pdf, à la qualité près, sans prendre 30 minutes parce que toutes mes images hautes résolutions tuent les performances)

    Ma plus grosse limitation actuellement, hormis le coté code non robuste et pas du tout vendable, c'est que cela ne gère pas la construction en parallèle des dépendances.

    Donc pour conclure, je cherche un outil plus puissant pour générer mes dépendances. Actuellement j'ai une solution foireuse qui fonctionne, mais pas très sérieuse.