如何在 Windows 上更新 Perl 而不丢失模块？
在工作中，我在 Windows 上使用 Perl 5.8.0。
当我第一次安装 Perl 时，我去了 CPAN，下载了所有源代码，做了一些更改（在 .MAK 文件（？）中以支持线程或类似的东西），然后执行了 nmake / nmake 测试 / nmake 安装。 然后，我一点一点地从 CPAN 下载了各个模块并完成了 nmake 的舞蹈。
因此，我想升级到更新的版本，但新版本不得破坏任何现有脚本。 值得注意的是，我安装的一堆“使用”模块必须安装在新版本中。
更新当前版本最可靠（也是最简单）的方法是什么，确保更新后我用 nmake dance 所做的一切仍然存在？
At work I'm using Perl 5.8.0 on Windows.
When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file(?) to support threads, or things like that), and did nmake / nmake test / nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.
So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.
What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance will still be there after updating?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
正如其他人指出的，首先将新的 Perl 安装在单独的位置。 我安装了几个 perls，每个都与其他所有完全分开。
为此，您必须自己配置和编译源代码。 当您运行
configure时，您将有机会指定安装程序。 我在 The Perl Review 2008 年春季刊<的“编译我自己的 Perl”中给出了详细的说明。 /a>. 有效的 Perl 编程 中还有一个项目向您展示了如何做到这一点。现在，返回到原始发行版并运行 cpan -a 来创建自动捆绑文件。 这是一个 Pod 文档，列出了您安装的所有额外内容，CPAN.pm 知道如何使用它来重新安装所有内容。
要在新的 perl 中安装内容，请使用该 perl 的路径启动 CPAN.pm 并安装您创建的自动捆绑文件。 CPAN.pm 将从该 perl 的配置中获取正确的安装路径。
观察输出以确保一切顺利。 此过程不会安装相同版本的模块，而是安装最新版本。
至于 Strawberry Perl，有一个“便携式”版本，您可以安装在默认位置之外的其他位置。 这样您就可以在可移动媒体上拥有新的 Perl。 您可以在任何地方进行测试，而不会影响本地安装。 但我认为这还没有准备好用于一般用途。 Berrybrew 工具可能会帮助您管理它。
祝你好运， ：）
As others noted, start by installing the new perl in a separate place. I have several perls installed, each completely separate from all of the others.
To do that, you'll have to configure and compile the sources yourself. When you run
configure, you'll get a chance to specify the installer. I gave detailed instructions for this in an "Compiling My Own Perl" in the Spring 2008 issue of The Perl Review. There's also an Item in Effective Perl Programming that shows you how to do it.Now, go back to your original distribution and run
cpan -ato create an autobundle file. This is a Pod document that lists all of the extra stuff you've installed, and CPAN.pm understands how to use that to reinstall everything.To install things in the new perl, use that perl's path to start CPAN.pm and install the autobundle file you created. CPAN.pm will get the right installation paths from that perl's configuration.
Watch the output to make sure things go well. This process won't install the same versions of the modules, but the latest versions.
As for Strawberry Perl, there's a "portable" version you can install somewhere besides the default location. That way you could have the new perl on removable media. You can test it anywhere you like without disturbing the local installation. I don't think that's quite ready for general use though. The Berrybrew tool might help you manage that.
Good luck, :)
我会认真考虑使用 Strawberry Perl。
I would seriously consider looking at using Strawberry Perl.
我认为这个问题的答案涉及某种虚拟化：
这背后的想法是，可能存在您没有想到的各种微妙的依赖关系和假设。 虽然不太可能，但特定模块的最新版本（甚至可能是核心模块，尽管这种可能性更小）可能与您正在使用的模块有细微的差别。 除非您彻底浏览了整个代码库，否则很可能只有在某些情况下才需要某个特定模块。
您可以尝试通过构建所有脚本的列表来发现这一点 - 无论如何您都应该拥有一个列表，因为您的所有代码都处于版本控制之下（您正在使用版本控制，例如Subversion，是吗？） - 并迭代它，在每个脚本上运行
perl -c。 例如此脚本。 这种自动化测试是无价的：您可以将其设置为运行，出去喝杯咖啡或其他什么，然后回来检查一切是否正常。 最初几次，您可能会发现一个您忘记的不起眼的模块，这很好：自动化的全部目的是让您不必做苦差事。检查每个脚本。I think the answer to this involves virtualisation of some kind:
The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.
You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you are using version control, e.g. Subversion, yes?) - and iterating through it, running
perl -con each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that you don't have to do the drudge-work of checking every single script.如果您留在 5.8 轨道内，所有包含 XS（二进制）扩展的已安装模块将继续工作，因为在同一 5.8 系列中保证了二进制兼容性。 如果您迁移到 5.10，则必须重新编译包含 XS 组件的所有模块。
您需要做的就是确保新版本在其 @INC 数组（用于查找模块）中列出了先前的包含目录。
从听起来来看，我认为您使用的是 Windows，在这种情况下，可以使用“
确保将新的 Perl 版本定位在另一个目录中”来查看当前的 @INC 路径。 一定会幸福地共存
与以前的版本，这将允许您选择使用哪个 Perl 安装； 这只是一个整理你的 PATH 顺序的问题。 一旦 Perl 解释器启动，它就知道在哪里查找其余模块。
Strawberry Perl 可能是目前 Windows 上最适合您自己开发的发行版。
If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guaranteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.
All you need to do is ensure that the new build lists the previous include directories in its @INC array (which is used to look for modules).
By the sounds of it, I think you're on Windows, in which case the current @INC paths can be viewed with
Make sure you target your new Perl version in another directory. It will happily coexist
with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a Perl interpreter is started up, it knows where to look for the rest of its modules.
Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.
您可以在不同位置安装 Perl 的第二个版本。 您必须将所有非核心模块重新安装到新版本中。 一般来说，不同版本的 Perl 不是二进制兼容的，如果您有任何使用 XS 组件的特定于程序的库，这可能会成为一个问题。 纯 Perl 模块不应受到影响。
You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.
当我这样做时，我将较新的安装到一个单独的目录中。 运行两个版本会增加一些混乱，但它肯定有助于确保一切正常工作，并提供一种在紧要关头切换回旧版本的快速方法。 我还设置了 Apache 来运行两个独立的服务，这样我就可以在一项服务中使用较新的 Perl，而无需触及旧 Perl 上的生产服务。
事后看来，安装在单独的计算机上并在那里进行测试可能更明智。 记录您需要进行的每个配置更改。
我不确定是否要自己构建它 - 我总是只使用 Windows 的预打包二进制文件。
我不确定我是否完全理解你在问什么。 您有对 5.8 makefile 所做的更改列表吗？ 或者问题是如何获得这样的列表？ 您是否还想知道如何找出您从 CPAN 获得的基本安装之上的软件包？ 您是否还询问如何测试您的自定义更改在再次从 CPAN 获取这些软件包时不会破坏这些软件包？
When I did it I installed the newer one into a separate directory. There's a bit of added confusion running two versions, but it definitely helps make sure everything's working first, and provides a quick way of switching back to the old one in a pinch. I also set up Apache to run two separate services, so I could monkey around with the newer Perl in one service without touching the production one on the old Perl.
It's probably a lot wiser, in hindsight, to install on a separate computer, and do your testing there. Record every configuration change you need to make.
I am not sure about building it yourself—I always just used prepackaged binaries for Windows.
I'm not sure I understand exactly what you're asking. Do you have a list of changes you made to the 5.8 makefile? Or is the question how to obtain such a list? Are you also asking how to find out which packages above the base install you've obtained from CPAN? Are you also asking how to test that your custom changes won't break those packages if you get them from CPAN again?
为什么不使用 ActivePerl 及其“ppm”工具来（重新）安装模块？
Why don't you use ActivePerl and its "ppm" tool to (re)install modules?