Question

Au travail, j'utilise Perl 5.8.0 sous Windows.

Quand j'ai mis Perl pour la première fois, je suis allé sur CPAN, j'ai téléchargé toutes les sources, fait quelques modifications (dans le fichier .MAK? pour supporter les threads, etc.), puis nmake / nmake test / nmake install . Puis, peu à peu, j'ai téléchargé des modules individuels de CPAN et fait la danse nmake.

Donc, j'aimerais passer à une version plus récente, mais la nouvelle ne doit pas casser les scripts existants. Notamment, un groupe de "utiliser" les modules que j'ai installés doivent être installés dans la nouvelle version.

Quel est le moyen le plus fiable (et le plus simple) de mettre à jour ma version actuelle, en veillant à ce que tout ce que j'ai fait avec la danse nmake soit toujours disponible après la mise à jour?

Était-ce utile?

La solution

Comme d'autres l'ont noté, commencez par installer le nouveau Perl dans un endroit séparé. J'ai plusieurs perls installés, chacun complètement séparé de tous les autres.

Pour ce faire, vous devrez configurer et compiler vous-même les sources. Lorsque vous exécutez configure , vous aurez la possibilité de spécifier le programme d'installation. J'ai donné des instructions détaillées à ce sujet dans la section "Compiling My Own Perl". dans le numéro du printemps 2008 de The Perl Review . Il existe également un élément dans Programmation Perl efficace qui vous explique comment procéder.

Maintenant, revenez à votre distribution d'origine et exécutez cpan -a pour créer un fichier de regroupement automatique. Ceci est un document Pod qui répertorie tous les éléments supplémentaires que vous avez installés, et CPAN.pm comprend comment l’utiliser pour tout réinstaller.

Pour installer des éléments dans le nouveau Perl, utilisez son chemin d'accès pour démarrer CPAN.pm et installez le fichier Autobundle que vous avez créé. CPAN.pm obtiendra les bons chemins d’installation à partir de la configuration de ce perl.

Regardez la sortie pour vous assurer que tout se passe bien. Ce processus n'installe pas les mêmes versions des modules, mais les dernières versions.

En ce qui concerne Strawberry Perl , il existe un "portable". version que vous pouvez installer quelque part en plus de l'emplacement par défaut. De cette façon, vous pourriez avoir le nouveau Perl sur un support amovible. Vous pouvez le tester où bon vous semble sans perturber l'installation locale. Je ne pense pas que ce soit tout à fait prêt pour une utilisation générale cependant. Le Berrybrew Cet outil pourrait vous aider à gérer cela.

Bonne chance, :)

Autres conseils

J'envisagerais sérieusement d'utiliser Strawberry Perl .

Vous pouvez installer une deuxième version de Perl à un emplacement différent. Vous devrez réinstaller tous les modules non essentiels dans la nouvelle version. En général, les différentes versions de Perl ne sont pas compatibles binaires, ce qui peut poser problème si vous avez des bibliothèques spécifiques à un programme qui utilisent des composants XS. Les modules Pure Perl ne devraient pas être affectés.

Si vous restez dans la piste 5.8, tous les modules installés contenant des extensions XS (binaires) continueront de fonctionner, la compatibilité binaire étant garantie dans la même série 5.8. Si vous avez migré vers la version 5.10, vous devrez recompiler tous les modules contenant des composants XS.

Tout ce que vous avez à faire est de vous assurer que la nouvelle construction répertorie les répertoires include précédents dans son tableau @INC (utilisé pour rechercher des modules).

En apparence, je pense que vous êtes sous Windows, auquel cas les chemins @INC actuels peuvent être visualisés avec

perl -le "print for @INC"

Assurez-vous de cibler votre nouvelle version de Perl dans un autre répertoire. Il va volontiers coexister avec la version précédente, ce qui vous permettra de choisir l’installation Perl à utiliser; il s’agit simplement de régler votre commande PATH. Dès qu'un interpréteur Perl est démarré, il sait où chercher le reste de ses modules.

Strawberry Perl est probablement la meilleure distribution sur Windows de nos jours.

Je pense que la réponse à cette question implique la la virtualisation :

  1. Configurez une copie exacte de votre ordinateur live actuel. Mettez Perl à niveau, en utilisant les mêmes emplacements et répertoires que ceux que vous utilisez actuellement.
  2. Parcourez vos scripts en les testant sur la nouvelle image.
  3. Une fois que vous êtes satisfait, actionnez le commutateur.

L’idée sous-jacente est qu’il existe probablement toutes sortes de dépendances et d’hypothèses subtiles auxquelles vous n’avez pas pensé. Bien que peu probable, la dernière version d’un module particulier (peut-être même un module principal, bien que cela soit encore plus improbable) peut présenter une différence subtile par rapport à celle que vous utilisiez. À moins que vous n'ayez parcouru l'intégralité de votre base de code, il est fort possible qu'un module particulier ne soit nécessaire que dans certaines circonstances.

Vous pouvez essayer de le repérer en construisant une liste de tous vos scripts - liste que vous devriez avoir de toute façon, à force que tout votre code soit sous contrôle de version (vous utilisez en utilisant le contrôle de version, Par exemple, Subversion , oui?) - et en le parcourant, en exécutant perl -c sur chaque script. par exemple. ce script . Ce type de test automatisé est inestimable: vous pouvez le configurer, vous aller prendre un café ou autre, et revenir pour vérifier si tout a fonctionné. Les premières fois, vous trouverez probablement un module obscur que vous avez oublié, ce qui est bien: l’intérêt de l’automatiser est que vous n’ayez pas à faire le travail fastidieux. de vérifier chaque script.

Quand je l’ai fait, j’ai installé le plus récent dans un répertoire séparé. Il existe un peu de confusion supplémentaire entre les deux versions, mais cela permet de s’assurer que tout fonctionne correctement en premier et offre un moyen rapide de revenir à l’ancienne. J'ai également configuré Apache pour qu'il exécute deux services distincts. Je pouvais donc naviguer avec le nouveau Perl dans un service sans toucher au service de production de l'ancien Perl.

Rétrospectivement, il est probablement plus sage d’installer sur un ordinateur séparé et de procéder aux tests. Enregistrez chaque modification de configuration que vous devez apporter.

Je ne suis pas sûr de le construire vous-même & # 8212; J'ai toujours utilisé des fichiers binaires pré-emballés pour Windows.

Je ne suis pas sûr de comprendre exactement ce que vous demandez. Avez-vous une liste des modifications que vous avez apportées au fichier make 5.8? Ou la question est de savoir comment obtenir une telle liste? Demandez-vous également comment trouver les packages au-dessus de l'installation de base que vous avez obtenus auprès de CPAN? Demandez-vous également comment vérifier que vos modifications personnalisées ne casseront pas ces packages si vous les recevez à nouveau via CPAN?

Pourquoi n'utilisez-vous pas ActivePerl et son " ppm " outil pour (ré) installer des modules?

alt text

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top