【问题标题】:Perl strategy for a new Snow Leopard user? [closed]新雪豹用户的 Perl 策略? [关闭]
【发布时间】:2010-12-31 20:28:00
【问题描述】:

我即将购买新的 iMac。这是我的第一台英特尔 Mac,可能会与 Snow Leopard 一起提供。其他用户会推荐什么作为在这台机器上安装和使用 perl 的正确策略?

我知道我已经阅读了一些关于 Leopard 附带的 Perl 版本(或者是 CPAN 版本?)的投诉,尽管快速 google 并没有提出太多建议。

我假设一个好的策略是不理会系统 perl 并安装我自己的,但你会使用什么? Fink,Macports,也许 XAMPP for Mac?

对于以前没有在英特尔 mac 上使用过 Perl 的人有什么特别的问题吗?

我并不完全是一名高级开发人员,但我有很多实用程序脚本和 MySQL 数据库应用程序可以在我想要保留的旧机器上运行,我的主要工作是 Web 开发。

【问题讨论】:

    标签: perl osx-snow-leopard macports fink


    【解决方案1】:

    如果你像我一样,无论如何你都会安装macports(我将它用于 mutt、colordiff、fetchmail+ssl 等),这意味着你最终会在 /opt/local/bin 中获得第二个 perl /perl,这也会导致大量的 cpan 模块被添加到 /opt/local/lib。这些将完全独立于系统 perl(安装在 /System/Library 中)。由于 macports 默认只安装 perl 5.8.9(至少,这是我在安装大量 macports 发行版后通过依赖项最终得到的),而且 Apple 仍在将 perl5.10.0 与 10.6.2 捆绑在一起,你可能需要安装一个third perl(版本 5.10.1),其他地方。现在这开始变得复杂了......

    查看这个问题,尤其是 brian d foy 对How do you manage your Perl modules? 的回答。他讨论了他安装多个 perls 和管理其模块的策略。

    对我来说,我看不到需要 5.8.9 和 5.10.1 以外的版本,所以我只是从源代码直接下载/安装了 5.10.1 到 /usr/local/lib 和 /usr/local/ bin(即./Configure -de -Dprefix=/usr/local),其中我的PATH 使用命令/usr/local/bin:/opt/local/bin:/usr/bin。我不会对系统 perl 进行任何修改:Apple 将根据其内部系统的需要更新组件。此外,我不会对 macports perl 进行任何(手动)修改:当我安装新工具时,将通过依赖项下载和安装新模块。我的 PATH 的顺序将确保“cpan”命令不会触及这些安装(除非我先更改一些其他配置变量)。我只会将/usr/local中的版本用于自己的开发,直接通过CPAN管理其模块。

    (我还没有在我的新系统上安装 fink,但是如果我这样做了,我会像 macports perl 一样管理它:把它放在我的 PATH 中,而不是 /usr/local/bin,它只会得到通过安装依赖更新。)

    关于默认系统 Perl 破坏的东西,请参阅

    【讨论】:

      【解决方案2】:

      在使用 Mac OS X 和 perl 多年之后,我想出了一个简单的三部分计划:

      • 从源代码编译
      • 安装在/usr/local
      • 永远不要碰系统perl

      学习一下。知道。活下去。

      哦,好吧,我会尽力解释。完全接触系统 perl 是一个坏主意,我希望这是显而易见的原因。 Apple 的应用程序、第三方应用程序和操作系统本身期望系统 perl 的行为类似于系统 perl — 有时 完全 像系统 perl。仅举一个例子,有一次 iTunes 安装程序包含一个 perl 脚本,其中包含如下代码:

      if ($foo EQ $bar) {
          ....
      }
      

      是的,EQ 而不是 eq。信不信由你,这实际上在许多旧版本的 perl 中有效——但在我年轻时天真时安装在系统版本之上的新版 perl 中却不行。结果是我双击 iTunes 安装程序,实际上什么都不会发生。 (嘿,可能是a lot worse。)

      我们可以谈论 Apple 显然在那时编写 perl 代码的猴子种类(以及现在质量是否更好),但底线是 /System 是 Apple 的域。 Attempt no landing there。 (多么热门。)

      另一方面,Apple 长期以来一直承诺不会在 /usr/local 中添加任何内容,同样重要的是,在系统更新期间不会触及任何内容。这是你的安全区。在那里安装你的 perl,在那里安装 CPAN 模块所需的库等等。

      最后,为什么要从源代码构建?为什么不使用包管理器?这似乎只是脾气暴躁的老人的推理,但我更愿意将其视为来之不易的智慧。 Mac OS X 没有一个占主导地位的包管理系统,更不用说官方/内置的了。所有各种第三方包管理器都与我使用过的每个包管理器都存在相同的问题:有时你想要的软件没有打包,有时它没有按照你想要的方式打包,有时它只是被破坏了等等。除了从源代码构建一些软件之外,还尝试安装软件包是灾难的根源。

      唯一可行的“统一”方法是从源代码构建所有内容。如今,几乎所有常用的 Unix 软件都在 Mac OS X 上构建,无需任何特别努力。 (现在有如此多的 Unix 开发人员使用 Mac OS X 作为他们的个人系统,这很有帮助。)通常只是解压缩、配置、制作、安装。您甚至很少需要将/usr/local 指定为目的地;这是大多数软件的默认设置。

      所以你有它:从源代码编译。安装在/usr/local。永远不要触摸系统 perl。你不会后悔的。

      【讨论】:

      • +1 :顺便说一句,这个极好的建议适用于所有操作系统上预装的所有计算机语言。永远不要手动弄乱它们,总是留给操作系统自己的打包更新/补丁。
      【解决方案3】:

      我刚开始在系统 ​​perl 中使用local::lib。到目前为止,我对此非常满意。

      按照引导说明进行操作,然后设置环境变量以匹配 /Users/blah/.MacOSX/environment.plist 中的 local::lib 输出。

      【讨论】:

        【解决方案4】:

        Snow Leopard 附带的默认 Perl 非常好。它是 v5.10.0。实际上,我遇到的问题比 macports 少(例如 DBI)。我建议坚持使用默认的 Perl(和所有其他默认程序),直到遇到不适合您的东西。无需为了更新版本而烦恼更新版本...

        【讨论】:

        • 5.10.0 和 5.10.1 之间存在一些不兼容(例如智能匹配的语法),因此升级有一定的优势。
        • 升级的好处之一是智能匹配操作符有效。
        【解决方案5】:

        恕我直言,在任何操作系统上避免系统 perl 并安装您自己的总是一个好主意。在 MacOS X 上,只要下载源代码并编译它,我总是很幸运。 (这需要安装 MacOS X 开发者工具来获取 gcc 等;默认情况下不安装。)

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2011-01-30
          • 1970-01-01
          • 2012-12-10
          • 2011-03-05
          相关资源
          最近更新 更多