Macportsが単純なパッケージを構築するのにFOREVERを使用するのはなぜですか？
Macportsの外部のソースからビルドするのは簡単です。 macportsを使用したビルドには時間がかかり、OSが頻繁にフリーズするようです。これは典型的な動作ですか？ os xの素敵なパッケージツールのように見えますが、インストールのたびにこの苦痛を経験しなければならない場合、私はそれなしでやると思います。
Intel Core 2 Duoで実行している場合は、次の場所にあるMacports構成オプションを変更することで、ビルドの速度を2倍にすることができます。
/opt/local/etc/macports/macports.conf
# Number of simultaneous make jobs (commands) to use when building ports
buildmakejobs 2
私がgccを再構築した後でこれを発見したとき、私は自分を蹴っていました;）
このオプションを使用すると、パッケージのビルドに両方のCPUを使用できます。
「OSをフリーズ」？より具体的にできますか？どのパッケージをどのマシンのどのバージョンのOS Xでビルドしようとしていましたか？
私の経験では、MacPortsビルドは、サポートされているほとんどすべての構成で正常に動作します。私の場合、10.4で動作する256MB Pismo G3（2000年）から10.5の最近のデュアルコアIntel iMacまでです。ただし、我慢する必要があります。特に依存パッケージが多い場合は、時間がかかることがあります。これは、MacPortsやFinkなどのパッケージマネージャを使用する場合の欠点の1つです。有利な点は、ソースから個別にパッケージを自分でインストールする場合よりも、一般的にははるかに制御されたテスト環境があることです。また、まだ更新していない場合は、最新のMacPortsに更新してください。1.8.0がリリースされたばかりで、ユニバーサルビルドのサポートの向上など、いくつかの重要な改善が行われています。
MacPortsはソースからのビルドにのみ使用されていたため、バイナリをフェッチするパッケージシステムと比較すると、magnitudoの数次の違いが生じる可能性があります。ビルドに数時間かかる、なんとなく大きなパッケージの場合を例に考え、これを数十MBのサイズのアーカイブとしてダウンロードする時間と比較します。
MacPortsはAppleのツールを使用してビルドしますが、MacPortsの外で行うのと同じビルド時間に無視できるオーバーヘッドを追加するだけです。パッケージが大きいほど、差は小さくなります。 MPの外でプログラムをビルドするときに大きな違いが発生した場合は、詳細を含めて issue tracker でチケットを提出する必要があります。
とは言っても、2.0はバイナリアーカイブのサポートがあるので、質問はかなり古いと思います-cf。 Changelog -署名付きアーカイブを生成するビルドボットを備えたmacosforge対応のリポジトリがあり、デフォルトでは、ソースからビルドするのではなく、これらのバイナリアーカイブをフェッチします（-sフラグを使用して強制できます）。現在のユーザーエクスペリエンスは、apt-getなどのバイナリマネージャーに似ており、構成とビルドのオプションを非常に簡単に変更できます。
Mac Portsが最新のパッケージのソースからビルドされるのを待っていてもかまいません。しかし、このすべての処理能力を利用して、ビルドをMacPortsに自動的にアップロードするオプションをユーザーに提供しないでください。さらに、「ターボ」オプションを選択できる他のMacPortsユーザーにピアツーピアでハッシュおよび提供することをお勧めします。