Journal PAR::Packer et a2pdf : Du perl et du PDF sans interpréteur Perl

Posté par .
Tags : aucun
0
28
fév.
2008
Le contexte est le suivant :
Dans un cadre professionnel de réalisation d'un forfait hors des locaux du client, on a eu besoin de générer des rapports de tests (format texte ASCII) que l'on voulait fournir au format PDF pour limiter les risques d'altération.

Quand on parle d'extraction et de rapport on arrive assez vite au PERL. Le problème, c'est que ça doit tourner sur des machines (Windows&tm;) ...désolé) où l'on est pas sûr qu'un interpréteur PERL soit installé.

La solution existe !

  1. Il faut installer un module PERL (PAR::Packer) qui permet de "compiler" le script en un exécutable (.exe) Windows, via une commande en ligne pp.

  2. Il existe un module PERL App::a2pdf qui convertit de l'ASCII.
    Mais il ne semble pas dispo dans la distribution Active State.
    En revanche, il existe un exécutable a2pdf.exe, lui même obtenu via pp.


La mise en oeuvre est la suivante :

  • Génération du pdf :
    Dans le script, une fois le rapport généré dans une fichier texte, on appelle donc a2pdf via l'instruction system(a2pdf ...).

  • Génération du .exe via pp :
    Moyennant l'utilisation de l'option -i pour linker a2pdf.exe avec le script, on obtient un exécutable qui peut être lancé sur une machine où ni PERL ni a2pdf.exe ne sont installés.


Notez que pp offre beaucoup d'autres options ... à découvrir dans la doc :-) !
  • # pp c'est bien mais...

    Posté par . Évalué à 1.

    PP marche plutôt bien, je l'ai beaucoup utilisé et j'adore cette possibilité de pouvoir embarquer son script et un interpréteur Perl dans un exécutable.

    Malheureusement il arrive parfois que les exécutables qu'il produit refusent de démarrer sur certains postes en remontant une erreur sur une bibliothèque Perl manquante c'est le seul truc qui m'a bloqué pour l'utiliser dans de gros déploiements... bon a sa décharge il y avait 65 000 postes et on avait un pourcentage de postes en erreur minime lors du test préalable mais vu l'importance du parc on pouvais pas se le permettre. On a jamais trouvé l'origine de se soucis, aucun des postes impactés n'avait de cygwin ou une même de distribution Perl installée qui aurait pu provoquer un conflit.

    Je continue d'utiliser cette solution dans des contextes moins critiques et j'en suis très content car il n'y a rien de plus chiant que de devoir installer des distributions Perl à tout va et de devoir les maintenir pour exécuter une fois tous les 36 mois un script sur une machine.

Suivre le flux des commentaires

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