新しいiMacを手に入れようとしています。これは私の初めての Intel Mac で、おそらく Snow Leopard が付属するでしょう。このマシンに perl をインストールして使用するための正しい戦略として、他のユーザーは何を推奨しますか?
Leopard に同梱されている Perl のバージョン (または CPAN のバージョンでしたか?) に関する苦情をいくつか読んだことは知っていますが、Google で簡単に検索してもあまり情報が得られません。
システムの perl はそのままにして、独自の perl をインストールするのが良い戦略だと思いますが、何を使用しますか? Fink、Macports、Mac 用の XAMPP でしょうか。
以前に Intel Mac で Perl を使用したことがない人にとって、何か特別な落とし穴はありますか?
私は強力な開発者というわけではありませんが、古いマシンで実行するユーティリティ スクリプトと MySQL データベース アプリケーションをいくつか残しておきたいと考えています。私の主な仕事は Web 開発です。
Mac OS X と perl を何年も使用した後、単純な 3 つの部分からなる計画を思いつきました。
/usr/local学べ。それを知っている。それを生きる。
…
あ、わかりました、説明してみます。システム perl に触れることは、明らかな理由であると私が願っていることからして、悪い考えです。Apple のアプリケーション、サードパーティのアプリケーション、および OS 自体は、システム perl がシステム perl のように動作することを期待しています (システム perl とまったく同じ場合もあります) 。ほんの一例を挙げると、ある時点で、iTunes インストーラーには、次のようなコードを含む perl スクリプトが含まれていました。
if ($foo EQ $bar) {
....
}
はい、EQではなくeq。信じられないかもしれませんが、これは多くの古いバージョンの perl で実際に機能しますが、若い素朴な私がシステム バージョンの上にインストールした新しいバージョンの perl では機能しません。その結果、iTunes インストーラーをダブルクリックしても、文字通り何も起こりませんでした。（そしてねえ、それはもっと悪いことだったかもしれません。）
当時 Apple が明らかに perl コードを書いていたサルの種類について話すことはできますが (そして品質が今より良いかどうかは別として)、肝心なのはそれ/Systemが Apple のドメインであるということです。 そこに着陸しようとしないでください。（なんて話題。）
一方、Apple は、/usr/localシステムの更新中には何も入れないこと、そして同様に重要なことに、そこにあるものには何も触れないという長年の約束を持っています。これはあなたの安全地帯です。そこに perl をインストールし、そこに CPAN モジュールに必要なライブラリなどをインストールします。
最後に、なぜソースからビルドするのですか? パッケージマネージャーを使用しないのはなぜですか? これは不機嫌そうな老人の推論のように思えるかもしれませんが、私はそれを懸命に勝ち取った知恵だと考えています。Mac OS X 用の支配的なパッケージ管理システムは 1 つではなく、公式の組み込みのパッケージ管理システムは言うまでもありません。さまざまなサードパーティのパッケージ マネージャーにはすべて、私が使用したすべてのパッケージ マネージャーと同じ問題があります。必要なソフトウェアがパッケージ化されていない場合もあれば、希望どおりにパッケージ化されていない場合もあり、単純に壊れている場合もあります。など。また、ソースからいくつかのソフトウェアをビルドすることに加えて、パッケージをインストールしようとすると、災害のレシピになります。
唯一実行可能な「統一された」アプローチは、ソースからすべてを構築することです。最近では、一般的に使用されているほとんどすべての Unix ソフトウェアが、特別な努力なしに Mac OS X でビルドされています。(非常に多くの Unix 開発者が Mac OS X を個人用システムとして使用するようになったのは助かります。) 通常は、解凍、構成、作成、インストールを行うだけです。/usr/local宛先として指定する必要さえほとんどありません。これは、ほとんどのソフトウェアのデフォルトです。
ソースからコンパイルします。にインストールし/usr/localます。システム perl には決して触れないでください。後悔することはありません。
あなたが私のような人なら、とにかくmacportsをインストールするでしょう(私はこれを mutt、colordiff、fetchmail+ssl などに使用します)。また、膨大な数の cpan モジュールが /opt/local/lib に追加されます。これらは、システム perl (/System/Library にインストールされます) から完全に分離されます。macports はデフォルトで perl 5.8.9 のみをインストールします (少なくとも、多くの macports ディストリビューションをインストールした後に依存関係を介して最終的にそうなったものです)、Apple はまだ perl5.10.0 を 10.6.2 にバンドルしています。3 番目の perl (バージョン 5.10.1)、別の場所。今、これは複雑になり始めています...
この質問と、特にPerl モジュールをどのように管理するかに対する brian d foy の回答を参照してください。. 彼は、複数の perl をインストールし、そのモジュールを管理するための戦略について説明しています。
私にとっては、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 と同じように管理します: /usr/local/bin より後の PATH に保管し、インストールによってのみ更新されます。依存関係。)
デフォルトのシステム Perl の破壊的なものについては、以下を参照してください。
私見ですが、どの OS でもシステム perl を使用せず、独自のものをインストールすることを常にお勧めします。MacOS X では、ソースをダウンロードしてコンパイルするだけで、いつもうまくいきました。(これには、gcc などを取得するために MacOS X 開発者ツールをインストールする必要があります。デフォルトではインストールされません。)
システム perl でlocal::libを使い始めたところです。これまでのところ、私はそれにかなり満足しています。
ブートストラップの指示に従い、環境変数を のlocal::lib出力と一致するように設定します/Users/blah/.MacOSX/environment.plist。
Snow Leopard に付属しているデフォルトの Perl はかなり優れています。v5.10.0 です。実際には、macports よりも問題が少なくなっています (たとえば、DBI の場合)。自分に合わないものにぶつかるまで、デフォルトの Perl (および他のすべてのデフォルト プログラム) を使い続けることをお勧めします。新しいバージョンのためだけに新しいバージョンを気にする必要はありません...