最后，为什么要从源代码构建？为什么不使用包管理器？这可能看起来像是脾气暴躁的老人的推理，但我更愿意将其视为来之不易的智慧。 Mac OS X 没有一种占主导地位的包管理系统，更不用说官方/内置的了。所有各种第三方包管理器都与我使用过的每个包管理器都存在相同的问题：有时您想要的软件没有打包，有时它没有按照您想要的方式打包，有时它只是完全损坏等等。除了从源代码构建一些软件之外，尝试安装软件包会导致灾难。
唯一可行的“统一”方法是从源头构建一切。如今，几乎所有常用的 Unix 软件都是在 Mac OS X 上构建的，无需任何特殊的努力。 （这有助于许多 Unix 开发人员现在使用 Mac OS X 作为他们的个人系统。）通常只需解压、配置、制作、安装即可。您甚至很少需要指定 /usr/local 作为目标；这是大多数软件的默认设置。
After many years of using Mac OS X and perl, I've come up with a simple three-part plan:
Compile from source
Install in /usr/local
Never touch the system perl
Learn it. Know it. Live it.
…
Oh, alright, I'll try to explain. Touching the system perl at all is a bad idea for what I hope are obvious reasons. Apple's applications, third-party applications, and the OS itself expect the system perl to behave like the system perl—sometimes exactly like the system perl. To give just one example, at one point an iTunes installer included a perl script that contained code like this:
if ($foo EQ $bar) {
....
}
Yes, EQ rather than eq. Believe it or not, that actually works in many older version of perl—but not in the new version of perl I'd installed on top of the system version in my youthful naiveté. The result was that I'd double-click on the iTunes installer and literally nothing would happen. (And hey, it could have been a lot worse.)
We can talk about the kinds of monkeys Apple apparently had writing perl code back then (and wether the quality is any better now) but the bottom line is that /System is Apple's domain. Attempt no landing there. (How topical.)
On the other hand, Apple has a longstanding promise not to ever put anything in /usr/local, and just as importantly, not to touch anything that's there during system updates. This is your safe zone. Install your perl there, your libraries required by CPAN modules there, etc.
Finally, why build from source? Why not use a package manager? This may just seem like Grumpy Old Man reasoning, but I prefer to think of it as Hard-Won Wisdom. There is no one dominant package management system for Mac OS X, let alone an official/built-in one. All of the various third-party package managers come with the same problems as every package manager I've used: sometimes the software you want isn't packaged, sometimes it's not packaged the way you want it to be, sometimes it's just plain broken, etc. And trying to install packages in addition to building some software from source is a recipe for disaster.
The only viable "unified" approach is to build everything from source. These days, nearly all commonly used Unix software builds on Mac OS X without any special effort. (It helps that so many Unix developers now use Mac OS X as their personal systems.) It's usually just untar, configure, make, make install. You rarely even need to specify /usr/local as the destination; it's the default for most software.
So there you have it: Compile from source. Install in /usr/local. Never touch the system perl. You won't regret it.
If you're like me you will be installing macports anyway (I use it for mutt, colordiff, fetchmail+ssl etc), which means you will have ended up with a second perl in /opt/local/bin/perl, which will also result in a huge number of cpan modules being added to /opt/local/lib. These will be entirely separate from the system perl (installed into /System/Library). Since macports only installs perl 5.8.9 by default (at least, that's what I ended up with via dependencies after installing lots of macports distributions), and Apple is still bundling perl5.10.0 with 10.6.2, you will probably want to install a third perl (version 5.10.1), somewhere else. Now this is starting to get complicated...
See this question and particularly brian d foy's answer to How do you manage your Perl modules?. He discusses his strategies for installing multiple perls and managing its modules.
For me, I can't see a need for versions other than 5.8.9 and 5.10.1, so I simply downloaded/installed 5.10.1 from source directly into /usr/local/lib and /usr/local/bin (i.e. ./Configure -de -Dprefix=/usr/local), where my PATH uses the order /usr/local/bin:/opt/local/bin:/usr/bin. I will not make any modifications at all to the system perl: Apple will update components as needed for its internal systems. Furthermore, I will not make any (manual) modifications to the macports perl: new modules will be downloaded and installed via dependencies as I install new tools. The ordering of my PATH will ensure that the 'cpan' command will not touch these installs (unless I change some other config variables first). I will only use the version in /usr/local for my own development, and manage its modules via CPAN directly.
(I haven't installed fink on my new system yet, but if I do, I will manage it identically to the macports perl: keep it later in my PATH than /usr/local/bin, and it will only get updated via installation dependencies.)
Regarding the default system Perl breaking things, see
恕我直言，在任何操作系统上避免使用系统 perl 并安装自己的系统总是一个好主意。在 MacOS X 上，我总是很幸运地下载了源代码并编译它。 （这需要安装 MacOS X 开发工具才能获取 gcc 等；默认情况下不会安装。）
IMHO, it's always a good idea to avoid the system perl on any OS and install your own. On MacOS X, I've always had good luck just downloading the source and compiling it. (This will require an install of the MacOS X Developer Tools to get gcc and whatnot; it's not installed by default.)
The default Perl coming with Snow Leopard is pretty good. It's v5.10.0. I've actually had less problems with it than the macports one (for DBI for example). I'd recommend sticking with the default Perl (and all other default programs) until you bump into something that doesn't suit you. No need to bother with newer version just for the sake of newer versions...
发布评论
评论（5）
在使用 Mac OS X 和 perl 多年之后，我提出了一个简单的三部分计划：
/usr/local学习它。知道了。活下去。
……
哦，好吧，我会尽力解释一下。完全接触系统 perl 是一个坏主意，我希望这是显而易见的原因。 Apple 的应用程序、第三方应用程序和操作系统本身都希望系统 Perl 的行为与系统 Perl 类似，有时完全与系统 Perl 一样。仅举一个例子，iTunes 安装程序曾包含一个 perl 脚本，其中包含如下代码：
是的，
EQ而不是eq。不管你相信与否，这实际上在许多旧版本的 Perl 中都有效，但在我年轻时安装在系统版本之上的新版本 Perl 中却不起作用。结果是，我双击 iTunes 安装程序，却什么也没有发生。 （嘿，情况可能会更糟糕。）我们可以谈论苹果公司当时编写 Perl 代码的猴子类型（以及现在的质量是否更好），但底线是
/System是苹果公司的域名。 尝试不在那里着陆。 （多么热门。）另一方面，Apple 长期以来一直承诺不会在
/usr/local中放入任何内容，同样重要的是，在系统更新期间不会触摸其中的任何内容。这是你的安全区。在那里安装你的 perl，在那里安装 CPAN 模块所需的库，等等。最后，为什么要从源代码构建？为什么不使用包管理器？这可能看起来像是脾气暴躁的老人的推理，但我更愿意将其视为来之不易的智慧。 Mac OS X 没有一种占主导地位的包管理系统，更不用说官方/内置的了。所有各种第三方包管理器都与我使用过的每个包管理器都存在相同的问题：有时您想要的软件没有打包，有时它没有按照您想要的方式打包，有时它只是完全损坏等等。除了从源代码构建一些软件之外，尝试安装软件包会导致灾难。
唯一可行的“统一”方法是从源头构建一切。如今，几乎所有常用的 Unix 软件都是在 Mac OS X 上构建的，无需任何特殊的努力。 （这有助于许多 Unix 开发人员现在使用 Mac OS X 作为他们的个人系统。）通常只需解压、配置、制作、安装即可。您甚至很少需要指定
/usr/local作为目标；这是大多数软件的默认设置。现在你已经知道了：从源代码编译。安装在
/usr/local中。永远不要碰系统 perl。你不会后悔的。After many years of using Mac OS X and perl, I've come up with a simple three-part plan:
/usr/localLearn it. Know it. Live it.
…
Oh, alright, I'll try to explain. Touching the system perl at all is a bad idea for what I hope are obvious reasons. Apple's applications, third-party applications, and the OS itself expect the system perl to behave like the system perl—sometimes exactly like the system perl. To give just one example, at one point an iTunes installer included a perl script that contained code like this:
Yes,
EQrather thaneq. Believe it or not, that actually works in many older version of perl—but not in the new version of perl I'd installed on top of the system version in my youthful naiveté. The result was that I'd double-click on the iTunes installer and literally nothing would happen. (And hey, it could have been a lot worse.)We can talk about the kinds of monkeys Apple apparently had writing perl code back then (and wether the quality is any better now) but the bottom line is that
/Systemis Apple's domain. Attempt no landing there. (How topical.)On the other hand, Apple has a longstanding promise not to ever put anything in
/usr/local, and just as importantly, not to touch anything that's there during system updates. This is your safe zone. Install your perl there, your libraries required by CPAN modules there, etc.Finally, why build from source? Why not use a package manager? This may just seem like Grumpy Old Man reasoning, but I prefer to think of it as Hard-Won Wisdom. There is no one dominant package management system for Mac OS X, let alone an official/built-in one. All of the various third-party package managers come with the same problems as every package manager I've used: sometimes the software you want isn't packaged, sometimes it's not packaged the way you want it to be, sometimes it's just plain broken, etc. And trying to install packages in addition to building some software from source is a recipe for disaster.
The only viable "unified" approach is to build everything from source. These days, nearly all commonly used Unix software builds on Mac OS X without any special effort. (It helps that so many Unix developers now use Mac OS X as their personal systems.) It's usually just untar, configure, make, make install. You rarely even need to specify
/usr/localas the destination; it's the default for most software.So there you have it: Compile from source. Install in
/usr/local. Never touch the system perl. You won't regret it.如果你像我一样，你无论如何都会安装 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 捆绑在一起，因此您可能需要安装第三 perl（版本5.10.1），其他地方。现在这开始变得复杂......
请参阅这个问题，特别是 brian d foy 对 您如何管理 Perl 模块？。他讨论了安装多个 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 进行任何修改：苹果将根据其内部系统的需要更新组件。此外，我不会对 macports perl 进行任何（手动）修改：当我安装新工具时，将通过依赖项下载并安装新模块。我的 PATH 的顺序将确保“cpan”命令不会触及这些安装（除非我首先更改一些其他配置变量）。我只会将 /usr/local 中的版本用于我自己的开发，并直接通过 CPAN 管理其模块。（我还没有在我的新系统上安装 fink，但如果安装了，我将以与 macports perl 相同的方式管理它：将它保留在我的 PATH 中，而不是 /usr/local/bin，并且它只会通过安装进行更新依赖关系。）
关于默认系统 Perl 破坏的事情，请参阅
If you're like me you will be installing macports anyway (I use it for mutt, colordiff, fetchmail+ssl etc), which means you will have ended up with a second perl in /opt/local/bin/perl, which will also result in a huge number of cpan modules being added to /opt/local/lib. These will be entirely separate from the system perl (installed into /System/Library). Since macports only installs perl 5.8.9 by default (at least, that's what I ended up with via dependencies after installing lots of macports distributions), and Apple is still bundling perl5.10.0 with 10.6.2, you will probably want to install a third perl (version 5.10.1), somewhere else. Now this is starting to get complicated...
See this question and particularly brian d foy's answer to How do you manage your Perl modules?. He discusses his strategies for installing multiple perls and managing its modules.
For me, I can't see a need for versions other than 5.8.9 and 5.10.1, so I simply downloaded/installed 5.10.1 from source directly into /usr/local/lib and /usr/local/bin (i.e.
./Configure -de -Dprefix=/usr/local), where my PATH uses the order /usr/local/bin:/opt/local/bin:/usr/bin. I will not make any modifications at all to the system perl: Apple will update components as needed for its internal systems. Furthermore, I will not make any (manual) modifications to the macports perl: new modules will be downloaded and installed via dependencies as I install new tools. The ordering of my PATH will ensure that the 'cpan' command will not touch these installs (unless I change some other config variables first). I will only use the version in /usr/local for my own development, and manage its modules via CPAN directly.(I haven't installed fink on my new system yet, but if I do, I will manage it identically to the macports perl: keep it later in my PATH than /usr/local/bin, and it will only get updated via installation dependencies.)
Regarding the default system Perl breaking things, see
恕我直言，在任何操作系统上避免使用系统 perl 并安装自己的系统总是一个好主意。在 MacOS X 上，我总是很幸运地下载了源代码并编译它。 （这需要安装 MacOS X 开发工具才能获取 gcc 等；默认情况下不会安装。）
IMHO, it's always a good idea to avoid the system perl on any OS and install your own. On MacOS X, I've always had good luck just downloading the source and compiling it. (This will require an install of the MacOS X Developer Tools to get gcc and whatnot; it's not installed by default.)
我刚刚开始在系统 perl 中使用 local::lib 。到目前为止，我对此非常满意。
按照引导程序说明进行操作，然后设置环境变量以匹配
/Users/blah/.MacOSX/environment.plist中的local::lib输出。I just started using using local::lib with the system perl. So far, I'm pretty happy with it.
Follow the bootstrap instructions, then set environment variables to match
local::liboutput in/Users/blah/.MacOSX/environment.plist.Snow Leopard 附带的默认 Perl 非常好。这是 v5.10.0。事实上，我遇到的问题比 macports 少（例如 DBI）。我建议坚持使用默认的 Perl（以及所有其他默认程序），直到遇到不适合您的东西。无需为了更新版本而烦恼更新版本......
The default Perl coming with Snow Leopard is pretty good. It's v5.10.0. I've actually had less problems with it than the macports one (for DBI for example). I'd recommend sticking with the default Perl (and all other default programs) until you bump into something that doesn't suit you. No need to bother with newer version just for the sake of newer versions...