私はobjective-cとosxアーキテクチャが初めてです。フレームワークを構築してから、それを使用することから始めました。私はこの素晴らしいチュートリアルに従いました。
チュートリアル中に、フレームワークのターゲットの動的ライブラリのインストール名を@rpath/MyFramework.framework/Versions/A/MyFramework. [私の理解では、@rpathはローダーの (コンシューマーの)実行パス検索パスに展開される] に設定する必要がありました。
フレームワークをロードする責任は、フレームワークの作成者と消費者の作成者の間で分割されているようです。フレームワークの作成者が消費者の実行パス検索パスに関心を持つ必要がある理由を誰か説明してもらえますか? たとえば、フレームワークの作成者が動的ライブラリのインストール名を ( @rpathではなく) ランダムなディレクトリを指すように設定した場合、クライアントはどのようにしてフレームワークを使用できるでしょうか?
前もって感謝します。
フレームワークの使用方法に大きく依存します。また、フレームワークの構造がプラットフォーム上に長い間存在していたことを覚えておくことが重要です。
Apple が作成したようなシステム フレームワークの場合、フレームワークが既知の場所に保持されていることに非常に満足するでしょう。そのような場合、それらが使用するパスは OS に対して固定されており、誤って間違ったパスをロードしないことが保証されます。さらに、フレームワークのドキュメントに示されているように、これらのフレームワークは、使用回数に関係なく、マシンに 1 回だけロードされます ( Apple: フレームワークとはを参照)。ここでの利点はパフォーマンスであり、多くの場合、コードとリソースの両方に当てはまります。
フレームワークの場所をランダム化するという最近の動きと、Apple のリリース ノートでのコメント「Mountain Lion はシステムの起動時にカーネル、kext、およびシステム フレームワークをランダムに再配置する」ため、これらのリソースをまだ共有しているように見えます。この利益から得ます。
組み込みフレームワークの場合、状況はより退屈であり、Apple はフレームワークがどこにあっても簡単に見つけられるように、長年にわたってさまざまな方法を試してきました。繰り返しになりますが、共有の性質上、共通のライブラリ要件を共有するアプリケーションがマシン上でそれらを共有することは理にかなっています。これは、効率化の目的と、データを共有している場合はそれらが同じバージョンであることを確認するためです。 . したがって、たとえば、同じフレームワークを使用して共有データを操作する 2 つの別個のアプリがある場合、共有フレームワークを配置し、/Library/Frameworks両方のアプリが明示的にそれを検索するようにして、他の (おそらく古い) バージョンの別のアプリによって読み込まれたフレームワークは、代わりに使用されません。
最終的に、フレームワークのプロデューサーとコンシューマーには、現在の動作方法で多くの柔軟性があります。これは、フレームワークがマシン上に存在するかどうかに応じて、開発者がフレームワークを共有するか、フレームワークのプライベート コピーを含めるか、またはその両方を行うかを決定できることを意味します。ただし、その柔軟性の代償は、今日の複雑さです。
特に使用したくない理由のもう 1 つの例は@rpath、緊密にリンクされた組み込みフレームワーク (そうです、人々は他のフレームワーク内にフレームワークを埋め込みます) です。このような場合、最初のフレームワークがどこにロードされているかわかりませんが、組み込みフレームワークをその中に入れて、それらが一緒に残るようにしたいと考えています。この場合@loader_path、プラグインのフレームワークがそのリソースを正しく見つけることができるように、それをロードしているコードに相対的です。
誰かが動的ライブラリのインストール名 を「ランダムな」場所に設定するという具体的な例に答えて。この場合、その場所を知っている必要があります。他のプログラムによる再利用を思いとどまらせたい場合や、既知の共有場所にのみインストールする必要があるフレームワーク内に大きなリソースがあるためなど、誰かがこれを行う理由はたくさんあります。