Quel framework dois-je utiliser pour écrire des modules? [fermé]

Question

Quel est le meilleur cadre pour l'écriture de modules - ExtUtils :: MakeMaker (h2xs ) ou Module :: Build ?

Answer 1

REMARQUE Ce conseil est obsolète. Module :: Build a été supprimé du noyau Perl mais vit comme un module CPAN. Les avantages et les inconvénients sont toujours valables et mes opinions sur MakeMaker sont toujours valables.

En tant qu'ancien responsable d'ExtUtils :: MakeMaker, j'aime recommander Module :: Build car MakeMaker est un spectacle d'horreur. Module :: Build est tellement mieux mis en place. Mais ce ne sont pas vos préoccupations et je vais vous présenter mon "moins de tracas pour vous". répondre.

Résumé:

Etant donné que la prise en charge de Module :: Build n'est pas à 100% en place dans Perl, commencez par MakeMaker. Si vous souhaitez effectuer une quelconque personnalisation, passez à Module :: Build. Étant donné que leur présentation de base, leurs options et leur interface sont presque identiques, cela ne présentera aucune difficulté. Aussi séduisant que cela puisse paraître, évitez Module :: Install.

Heureusement, Module :: Build peut émuler MakeMaker, ce qui en aide certains, mais ne vous aide pas si vous souhaitez effectuer une personnalisation. Voir Module :: Build :: Compat .

Pour les versions CPAN utilisant Module :: Build, c'est bien. Il y en a assez de Module :: Construire des choses sur CPAN maintenant que tout le monde s’occupe de le faire démarrer déjà.

Enfin, le nouveau configure_requires option permet aux shells CPAN de savoir installer Module :: Build avant de pouvoir commencer à construire le module. Malheureusement, seuls les derniers shells CPAN ont connaissance de configure_requires.

Oh, quoi que vous fassiez, n'utilisez pas h2xs (à moins d'écrire du code XS ... et même d'y penser).

Avantages de MakeMaker:

• est fourni avec Perl et utilisé par le noyau Perl (il est donc activement maintenu et le restera pour toujours)
• Tout sait quoi faire avec un Makefile.PL.
• La plupart de la documentation de création de module couvrira MakeMaker.
• Les utilisations de make (ceux qui connaissent make peuvent déboguer et patcher la construction processus)

MakeMaker Cons:

• Nécessite make (pensez à Windows)
• Difficile à personnaliser
• Encore plus difficile à personnaliser et à multiplier les plates-formes
• Difficulté à déboguer en cas de problème (à moins que vous ne compreniez make)

Module :: Constructeurs:

• Plus facile à personnaliser / sous-classe
• Pure Perl
• Plus facile à déboguer (c'est Perl)
• Peut émuler MakeMaker de plusieurs manières
• Le shell CPAN installera Module :: Build for you

Module :: Contre la construction:

• Les responsables du module :: Les responsables de la compilation (et tous les membres du groupe Perl Toolchain Gang) le détestent
• Les anciennes versions des clients CPAN (y compris CPANPLUS) ne connaissaient rien de Module :: Build.

Module :: Install Pros:

• interface lisse
• Bundles lui-même, vous avez une version connue
• Tout sait comment traiter un Makefile.PL

Module :: Cons. d'installation:

• Requiert la marque
• Utilise toujours la version groupée, vulnérable aux ruptures externes
• Difficulté à personnaliser en dehors de son interface
• Mucks avec les tripes de MakeMaker afin qu'une nouvelle version de MakeMaker finisse par le casser.
• Ne sait pas comment générer un fichier META à l'aide de la méta-spécification v2 (problème avec les nouveaux outils)

Answer 2

Il y a deux questions ici.

Tout d'abord, n'utilisez jamais h2xs. C’est une vieille perversité, bien que je suppose que si vous essayez de convertir un fichier d’en-tête en code XS, cela pourrait être utile (jamais fait cela moi-même).

Mise à jour 2011: je vous recommande vivement de consulter Dist :: Zilla , surtout si vous pensez que vous ' Vous conserverez plusieurs modules.

Pour créer un nouveau module, utilisez Module :: Starter. Cela fonctionne très bien et a quelques bons plugins pour personnaliser la sortie.

Deuxièmement, vous demandez quel système de construction vous devriez utiliser. Les trois concurrents sont ExtUtils :: MakeMaker (EUMM), Module :: Build (MB) et Module :: Install (MI).

EUMM est un travail horrible et méchant, mais cela fonctionne. Si vous ne personnalisez pas du tout votre processus de construction, cela fonctionne très bien.

MB est le petit dernier et ses détracteurs. Le gros avantage est que, si vous souhaitez fortement personnaliser votre processus d'installation et de construction, il est tout à fait possible de le faire de manière saine (et de manière multiplate-forme) à l'aide de MB. Ce n'est vraiment pas possible avec EUMM.

Enfin, MI est fondamentalement un wrapper déclaratif au-dessus de EUMM. Il s’emballe également avec votre distribution pour tenter de résoudre les problèmes rencontrés par les utilisateurs essayant d’installer des modules avec d’anciens modules de la chaîne d’outils. Les inconvénients du "package self" " Le truc, c’est que s’il ya un bogue dans MI lui-même, vous devez republier tous vos modules pour le réparer.

En ce qui concerne la personnalisation, il existe quelques plugins pour MI, mais si vous voulez aller au-delà de ceux-ci, vous vous retrouverez face au problème de gestion des Makefiles et de la construction d'outils sur une douzaine de plates-formes. va vous aider trop dans ce domaine.

Answer 3

Je viens de télécharger Distribution :: Cooker dans CPAN. C'est ce que j'utilise pour faire de nouvelles distributions. La bonne chose à ce sujet est que vos distributions peuvent être ce que vous voulez: vous ne faites que préparer des modèles. Je m'en fiche si quelqu'un l'utilise. Pour moi, c’est simple, peu technique et ne pose pas de problèmes supplémentaires.

Vous pourriez commencer par quelque chose comme Module :: Starter pour créer vos modèles de départ. Ajoutez ensuite votre propre passe-partout et votre façon préférée de faire les choses. Vous choisissez non seulement ce que vous voulez dans chaque fichier, mais également les fichiers qui apparaissent dans la distribution. Lorsque vous déterminez comment vous aimez faire les choses, vous mettez simplement à jour vos propres modèles.

En ce qui concerne Makemaker et Module :: Build, l'avenir est Module :: Build . Il n'y a plus que nous, les vieux, qui utilisons Makemaker. :) Il existe des moyens d'utiliser les deux (ou de prétendre les utiliser) en même temps. Examinez les modules :: build, module :: build :: compat et module :: install docs . Module :: Build a été mis à la porte de la bibliothèque standard de Perl et son avenir est incertain. Il est de retour à Makemaker en tant que système de construction.

Même s’il s’agit là d’une réponse peu probable, essayez d’utiliser chacun d’entre eux pour obtenir un peu d’expérience.

Answer 4

Vous pouvez également consulter Dist-Zilla , qui est une nouvelle outil réservé aux auteurs pour créer des distributions. Parce que cela aide simplement à construire la distribution, il ne contient ni votre code ni aucune installation, il peut faire beaucoup de choses puissantes.

Answer 5

Le seul problème de compatibilité concernant Module :: Build concerne les tentatives d'installation de modules sans mettre à jour leur client CPAN (CPAN.pm ou CPANPLUS.pm). S'ils installent votre module à partir du CPAN, ils peuvent tout aussi facilement mettre à niveau leur client à partir du même miroir.

Si vous ne voulez pas faire quoi que ce soit dans votre processus de construction, assurez-vous d'utiliser EUMM. Mais si vous rencontrez un problème de compilation sur une plate-forme cible différente, vous pouvez vous retrouver dans le Makefile, qui est différent pour chaque variante de make.

Module :: Build vous donne beaucoup de fonctionnalités (tout ce à quoi vous pouvez penser si vous l'étendez) et est tout en Perl pour que vous ne finissiez jamais par déboguer un fichier Make. Module :: Install vous donne des fonctionnalités, mais vous devez les regrouper et tout finit par exécuter 'make' à la fin.

Answer 6

Je recommande également Module :: Build et Module :: Starter (avec le plugin TT2 ).

Answer 7

Module :: Build est meilleur par tous les moyens, mais il est moins largement pris en charge que ExtUtils :: MakeMaker (plus précisément, les anciennes versions de Perl ne le supportent pas immédiatement). Cela dépend de vos besoins.

Answer 8

Personnellement, je recommande Module :: Install, comme beaucoup de personnes que je connais - des personnes comme Catalyst et Moose l’utilisent également.

Answer 9

Voici une petite clarification de l'orientation que j'espérais que les réponses prendraient:

• avantages / inconvénients de divers cadres
• compatibilité / base d'installation des frameworks
• compatibilité pour les versions internes (locales) par rapport aux versions externes (CPAN)
• pas nue "utilisez X" réponses

La réponse de Dave a de bons résultats / con info. La réponse de Leon fait allusion à la compatibilité mais n'est pas explicite . Comme brian d foy mentionné , seuls les vieux chapeaux utiliser EUMM, mais je ne suis pas convaincu que le MB soit un bon cadre pour les choses destinées au CPAN, car il ne fait pas partie du coeur du jeu jusqu’à la version 5.9.

Answer 10

Les deux présentent des avantages et des inconvénients. Ces jours-ci j'utilise et recommande Module :: Build et Module :: Starter.

Answer 11

EU :: MM semble toujours être le plus populaire et le plus largement pris en charge, mais Module :: Build rattrape son retard. Découvrez également Module :: Starter un module qui vous aidera à démarrer. .