21

これは、Xcode 4.5.x iOS armv7 armv7s および sim 用であり、特に Xcode プロジェクトのセットアップ/プロジェクトのビルド セットアップに関するものです。

アプリストアのアプリであるプロジェクト「A」があります。A で依存関係として使用されるライブラリであるプロジェクト "B" がありますが、アプリで使用するためにサードパーティ ライブラリとして他の企業にも配布されます。(この場合、他社のサードパーティ アプリは "Y" として表されます)。

要件は次のとおりです。

  • 同じビルド/セッションで、「A」をデバッグモードで実行し、ネストされた「B」プロジェクトを同時にデバッグできる必要があります。
  • "A" から、"B" のメソッド シグネチャを CMD + クリックして、その src ファイルに直接ジャンプできます。そこでは、同じプロジェクトからのものであるかのように、自由に編集してから再コンパイルできます。
  • 他の会社の開発者「X」は、ライブラリ「B」を自分のプロジェクト「Y」に簡単にドラッグできる必要があります。ここで、「B」は必要なヘッダー ファイルのみが公開された静的ライブラリです。もちろん、「Y」は「B」の実際のヘッダー ファイルのサブセットからメソッドを呼び出します。Dev "X" の配布には、このサブセットのファイルのみを含める必要があります。
  • Dev "X" は Xcode プロジェクトで何も変更する必要はありません。"B" のフォルダー (静的ライブラリとヘッダー ファイルのサブセットを含む) をプロジェクトにドラッグし、[リソースのコピー、参照の作成など] をクリックします。 "。
  • 依存プロジェクト「A」内でこのプロジェクト「B」を反復およびデバッグするときに、この間ずっと編集してきたのと同じファイルに基づいて、「B」のスタティック ライブラリ ビルドを簡単に生成できる必要があります。
  • 「B」には、ソース コード以外のリソースはありません。画像アセット、xib、またはそのようなものはありません。
  • 「B」から「アーカイブ」をクリックして、ポンッ！必要なヘッダー ファイルを配布する準備ができている静的ライブラリがあります (つまり、シミュレーター + armv7 + armv7sで動作するという意味で、ファット バイナリである必要があります!!)。
  • これらはすべて、アプリ ストアの承認に対応する必要があります。
  • また、これは信頼できるものでなければなりません。1 つのファイルを追加するたびに何度も設定を変更しなければならないのは良くありません。

更新:
* 最も重要: これは、探しているものの完全なエンドツーエンドのテンプレートであるチェックアウトできるリポジトリである必要があり、Xcode 4.5.2+ を開いて再生をクリックできる必要があります。このものが構築されているのを見てください。

上記の「A」、「B」、および「Y」(「B」静的ライブラリを dep として使用) のすべてを示すテンプレート プロジェクトを提供してくれる人なら誰でも500 点です。必要なのは、これを行う方法を示す一連のスケルトン プロジェクト (「A」、「B」(「A」内にネスト)、および「Y」) だけです。懸賞金が投稿されるまで、回答を差し控えないでください。それが私の要件を満たしていれば、あなたが私の報奨金ポイントを確実に獲得できるようにします。

Xcode の制限により、完全な面倒ではない方法でこれを行うことさえできないのではないかと少し心配しています。私が間違っていることを証明してください。

更新: armv6 はもう気にしないことにしました。さようなら、armv6。 armv7、armv7s、i386/simulator と一緒に armv6 を dist 出力にロールインできる場合は、追加のクレジット。

PS私はポイントを合理的に授与することを約束します. 技術的な理由でそれらを差し控えるつもりはありません。この 1 つの分野で私の人生の苦痛を劇的に軽減していただければ、喜んでポイントを差し上げます。

4

3 に答える 3

6

これは、Xcode だけでは不可能です。コンパイル ターゲット スイッチ (シミュレーター、デバイスなど) のため、いくつかのビルド スクリプト (もちろん Xcode 内から呼び出すことができます) が必要になります。

少なくとも「ファイルのコピー」ビルドステップに配布ヘッダーを追加する必要があると思います。ただし、何かを変更する場合、他の変更は必要ありません。

私は libturbojpeg に対してこのようなことをしました。参照用にhttps://github.com/dunkelstern/libturbojpeg-iosを参照してください。現在、ターミナルから「build.sh」ファイルを呼び出すと、ファット ライブラリが「lib」に配置されますが、配布ヘッダーは省略されます。libturbojpeg の場合、2 つのプロジェクト ファイルが必要でした。これは、各ターゲットが異なるサブセットのアセンブラー ファイルをライブラリにコンパイルするためです (アセンブラーの makefile を調べない方がよいでしょう)。コンパイルするには、最新バージョンの NASM が必要です。これは、Apple が出荷するバージョンが古いためです (brew で入手してください)。このようなライブラリ ビルド プロジェクトのテンプレートを同じアカウントに近日中に投稿します。（適切なリンクを使用してここで編集またはコメントします）

基本的には次のように機能します。

  1. xcodebuild必要な各プラットフォーム ターゲットを呼び出すビルド スクリプトを作成する
  2. Xcode ライブラリ プロジェクトには、ビルド スクリプトが検出できるディレクトリにビルド済みライブラリをドロップするスクリプトが含まれている必要があります。
  3. 追加のヘッダーは、「ファイルのコピー」ターゲット アクションによってコピーする必要があります。
  4. ビルド スクリプトは、すべてのライブラリ ビルドをマージする必要があります。lipo
  5. ビルド スクリプトを「Run Script」ターゲットとしてビルドに追加しますが、無限ループを作成しないことに注意してください (または、リリース ビルドを作成するためにターミナルから呼び出すだけです)。
  6. メイン プロジェクトにライブラリ サブプロジェクトを追加します。

次に、コピーされたヘッダー ファイルとlipoマージされたユニバーサル ライブラリを含む出力ディレクトリを配布し、ライブラリを通常どおりにワークスペース内のサブプロジェクトとして使用できます (ユニバーサル ライブラリではなく、必要なライブラリのみをビルドおよびリンクしますが、それは必要です)。問題ありません）

これは、実際には、ライブラリーの DSYM ファイルを作成する問題を解決するものではありません。ただし、通常、デバッグ ビルドをビルドする場合、デバッグ シンボルはライブラリ自体にある必要があります。リリース ビルドでデバッグ シンボルが削除され、DSYM がなくなります。

サンプル プロジェクトへのリンク: https://github.com/dunkelstern/StaticLibraryTemplate

于 2012-11-08T14:01:56.427 に答える
3

私はhttps://github.com/jverkoey/iOS-Frameworkを使用して、ニーズに非常に似たものを実現しています。彼にすべての信用を与えてください、私はそれをどのように行うかを要約しているだけです.

いつものように静的ライブラリを作成し、さらに次の調整を行います。

  • ヘッダーをコピーするファイルのコピー フェーズを追加します。iOS静的ライブラリには推奨されていない場所を読んだので、適切な「ヘッダーのコピー」フェーズを使用しません。
    • 宛先: 製品ディレクトリ
    • サブパス:${PROJECT_NAME}/Headers
  • いくつかの設定を変更します。
    • "Dead Code Stripping" => いいえ (すべての設定に対して)
    • 「コピー中にデバッグ シンボルを削除する」=> いいえ (すべての設定に対して)
    • "Strip Style" => Non-Global Symbols (すべての設定)
  • ライブラリを使用してフレームワークを準備する実行スクリプトを追加します。
    • スクリプトを使用しますprepare_framework.sh。

アプリで静的ライブラリ プロジェクトを使用できます。それをアプリ プロジェクトにドラッグし、.aライブラリを依存関係として追加してリンクします。アプリと共にライブラリをデバッグしたり、メソッドにステップインしたり、シンボル定義に移動したりできます。

準備されたフレームワークは、バイナリ バージョンを配布するために使用されます。

同じ静的ライブラリ プロジェクトに Aggregate ターゲットを追加します。

  • 静的ライブラリを依存関係として追加します。
  • 実行スクリプト フェーズを追加して、不足しているアーキテクチャを構築します。スクリプトを使用しますbuild_framework.sh。

スクリプトは、他のプラットフォームが何であるかを推測し、それを使用xcodebuildしてコンパイルします。次にlipo、すべてのアーキテクチャでファット バイナリを作成するために使用します。ファット スタティック ライブラリの宛先は、前に作成したフレームワーク ツリーになります。最終的なフレームワークは、ビルド フォルダー内の製品フォルダーにコピーされます。

このアプローチでは、次のことができます。

  • ネストされたプロジェクトとして静的ライブラリを使用してアプリをビルドおよびデバッグします。
  • フレームワークのようなバンドルに埋め込まれたヘッダーを使用して、ライブラリの配布可能なバージョンをワンステップで構築します。ビルドされたフレームワークは、プロジェクトの Products ディレクトリにあります。
  • Xcode のアーカイブ機能を使用します。何らかの理由で、最終ファイルがアーカイブの場所にコピーされません。これを使用して、フレームワークのストリップ バージョンを構築できます。

ライブラリをパッケージ化するために、この手法を使用してプロジェクトを自由に複製してください: json-framework fork。スクリプトを少し変更しました。iOS-frameworkのフォークを確認してください。

に関しては、古い iOS SDK 4.3 が必要で、有効なアーキテクチャと実際のアーキテクチャのリストにarmv6リテラルを手動で追加する必要があると思います。armv6現在、テストするための古い SDK はありません。

于 2012-11-15T17:36:20.580 に答える
2

ココアポッドはあなたのニーズをカバーします。これを使用する標準的な方法は、ポッドの仕様を中央の git リポジトリに送信することですが。配布用の代替リポジトリの追加、または手動での作成をサポートしています。こちらを参照してください。cocoapods を使用する利点は、すべての要件を満たし、ライブラリ (facebook や stackmob などの企業で使用) やオープン ソース (afnetworking など) を配布する非常に標準的な方法になりつつあることです。そのため、現在または将来サードパーティのライブラリに依存する場合、cocoapods がその依存関係の処理に役立つ可能性があります。

于 2012-11-22T01:01:41.370 に答える