3

他のオープンソース ライブラリに依存する iOS ライブラリを作成しています。どうやら同じ名前の 2 つのクラスを持つことはできないため、ライブラリがコンパイルされ、それを使用する可能性のあるプロジェクトもコンパイルされる可能性がありますが、(リンク段階で) 一緒にうまく動作しません。

このライブラリは多くのユーザーを対象としているため、これらの開発者が同じライブラリをインポートするかどうか、または同じライブラリの互換性のない別のバージョンを使用する可能性があるかどうかについて、私は推測できません。

私は周りを見回してきましたが、私の問題に対する明確な解決策を見つけることができませんでした (おそらくそうではありません)。これまでのところ、次のオプションを考えています。

  • X ライブラリが既にプロジェクトに含まれているため、それらも含めないことをユーザーに通知します。これは、異なるバージョンの X ライブラリを使用できないことを意味します。
  • 最初のものの洗練されたバージョンとして、依存関係が自動的に解決されるように CocoaPods を使用します。それでも、2 つのバージョンのライブラリが共存できないという欠点があります。
  • 私のライブラリが依存するすべてのクラスをインポートして名前を変更し、それらにプレフィックスを付けて、名前が元のクラスと競合しないようにします。これは面倒な作業ですが、さらに重要なことに、コードが大きく変更されるため、元のライブラリとの間でコードをプル/プッシュすることができないという欠点があります。ユーザーの観点からは、依然として最良の選択肢のように思えます。

より良いアイデアを思いつくことができますか？私は図書館プロジェクトにかなり慣れていないので、明らかに欠けているものがあるかもしれません。

バイナリ形式で配布するか、ソース コード形式で配布するかはまだ決まっていません。どちらかを選択する理由があれば、あなたの意見も聞きたいです。

4

2 に答える 2

0

この問題に直面したとき、私は 3 番目のオプションを選択し、ライブラリ内の依存クラスにプレフィックスを付けました。ユーザーに他のインポートを任せるのではなく、これを行うことを検討したい理由は、互換性を保証でき、依存しているユーザーのバージョンについて心配する必要がないからです。

于 2013-01-24T19:13:58.150 に答える
0

最初のポイント -

X ライブラリがプロジェクトに既に含まれていることをユーザーに通知するため、それらも含めないでください。

したがって、静的ライブラリFoolib.aがあり、サードパーティの依存関係Barlib.aがあります。Foolib をビルドするには、FoolibHEADER_SEARCH_PATHSを Barlib のパブリック ヘッダーのパスに設定する必要があります。もういや。

ソース コードを配布する場合は、CocoaPods を使用できます (これは良い方法です)。または、Barlib のリポジトリをリポジトリの git サブモジュール (または選択した VCS に合わせて) として追加し、HEADER_SEARCH_PATHSそのパスにハード コードすることができます。または、ユーザーが独自の Barlib を取得HEADER_SEARCH_PATHSし、正しいパスに手動で編集するように要求することもできます (CocoaPods またはサブモジュール ルートを使用する場合、ユーザーはこれも簡単に実行できるため、より多くのオプションがあります)。

Barlib からの何もあなたのプロジェクトにはありません。

一方、ユーザーがアプリにリンクするためのバイナリを配布する場合は、Foolib が Barlib をアプリにリンクする必要があることを指示で指定する必要があります。Barlib を入手する方法についての指示はいいでしょう。

Barlib からは何もプロジェクトに含まれていないか、ライブラリにコンパイルされていません。

2点目 -

CocoaPods を使用するため、依存関係は自動的に解決されます。ライブラリの 2 つのバージョンが共存できないという欠点があります。

1 つのアプリで同じライブラリの 2 つのバージョンを使用することは不可能ですが、エンド ユーザーが既に Barlib 3.0 を必要としており、Foolib を使用したいが、Foolib が Barlib 4.0 を必要とするという状況は決して発生する必要はありません - それは開発者次第です. Barlib の複数のバージョンを寛大にサポートできます (つまり、Foolib が機能するために必要なのは、アプリにリンクされた Barlib1.0、Barlib2.0、Barlib3.0 または Barlib4.0 だけです。iOS5 と iOS6 をサポートするアプリを作成するのと同様です)。または、意見があり、特定のバージョンが必要な場合があります。ユーザーが既に別のバージョンの Barlib を必要としている場合は、残念ながら、ライブラリを使用したい場合はコードを変更する必要があります。

3点目 -

ライブラリが依存するすべてのクラスをインポートして名前を変更し、プレフィックスを付けて、名前が元のクラスと競合しないようにします

これは、現時点で考えるにはあまりにもひどいことです。ごめん。

Barlib からの何ものも、あなたのプロジェクトの「中に」入ったり、あなたのライブラリにコンパイルされたりすることは決してありません。Barlib のコピーをバイナリにリンクしたり、ソース コードとして配布したりしません。

于 2013-01-24T21:51:53.657 に答える