18

$PROJECT/jniそのため、ディレクトリに配置した巨大な既存の C プロジェクトがあります。このプロジェクトは通常、configure スクリプトを実行して Makefile を作成し、プロジェクトを .NET 経由でコンパイルできるようにすることによって作成されmakeます。

このプロジェクトはかなり大きく、ソース ファイルとヘッダー ファイルを含む多くのディレクトリがあります。

ここでは、 がどのように機能するかについての基本的な理解が欠けていると思いますAndroid.mk。プロジェクトをコンパイルするために現在使用されているconfigureとmakefileを置き換えることになっていますか? それとも、configure スクリプトから生成された makefile を に組み込むのAndroid.mkでしょうか? 彼らが提供する例は、いくつかのソースファイルしかないかなり単純なものです。私のjniディレクトリは次のようになります。

jni/
  folder1/subfolder1
  folder1/subfolder2
  folder1/source
  folder2/source
  .....
  foldern/source
  configure/
  configure/configure.sh
  Makefile
  Android.mk

生成された makefile は非常に広範です (かなりの量の構成があり、すべてのディレクトリに 1 つ存在します)。

編集：

主な問題は、NDK に同梱されているサンプルが些細なサンプルであることです。最上位の jni ディレクトリに 3 ～ 5 個のソース ファイルがあります。私の問題は、これが複雑な構成の巨大なプロジェクトであり、それぞれに多くのサブディレクトリがある 4 つの最上位フォルダーがあることです。ソースを jni フォルダーに単純に移動して ndk コンパイラーを実行することはできません。

4

3 に答える 3

17

あなたの質問に答えるにAndroid.mk は、はい、Android ビルド システムです。Google は、このファイルの「言語」が GNU make マクロとして実装されていることをほとんど言及していません。ドキュメントでは、これらのマクロの観点からプロジェクトを説明する必要があります。それらは、汚れたクロスコンパイルの詳細をすべて処理します。Android.mk開発ツールが進化するにつれて、Google がこのアプローチを採用して、ファイルの前方移植性を改善したと確信しています。

結論としては (これを聞きたくないことはわかっています) 最良の答えはおそらく Android.mk、大きなプロジェクトに適した NDK をゼロから作成することです。

この記事では、約 800 個のファイルと 300k SLOC のライブラリを移植したときと同じ観察結果を示します。残念ながら、ほぼ 2 週間を費やして同じ結論に達しました。クロスコンパイルにより、少なくともいくつかのconfigureスクリプトが失敗します (エラーconfig.hファイルが生成されます)。彼が記事で使用している手法とほとんど同じ手法を「発明」しました。しかし、クリーン ビルドを行った後でも、結果の静的ライブラリは完全には機能しませんでした。デバッグに何時間も費やしましたが、有益な情報は得られませんでした。[注意: 私は設定ツールの専門家ではありません。教祖はおそらく私の誤りを発見したでしょう。] きれいな を作成するのに数日かかりましたAndroid.mk。結果のライブラリは、最初からすべてのテストを実行しました。また、開発ツールのいくつかのリビジョンを通じて、問題なく移植されています。

残念ながらconfigure、自動ツールなしで使用するライブラリを構築することconfig.hは、ターゲット環境用に手動で独自のライブラリを構築することを意味します。これは思ったほど悪くはないかもしれません。IME システムは、実際に使用するよりもはるかに多くのconfigure環境を定義する傾向があります。実際の依存関係を明確に把握することで、将来のリファクタリングで退屈な作業が報われる可能性があります。

記事の要約文はそれをすべて言います：

Autotool は GNU システムでのみ有効であり、クロス コンパイルに Autotool を使用すると、非常に面倒で、混乱し、エラーが発生しやすく、不可能になることさえあります。ここで説明する方法はハックであり、自己責任で使用する必要があります。

申し訳ありませんが、これ以上前向きな提案はありません。

于 2013-07-02T03:21:33.037 に答える
5

私の答えは、 Geneの答えと連携して最も効果的です。

./configureCの構成ファイルの作成は、各テストの小さなコード スニペットのコンパイル (および場合によっては実行) に基づいています。各テストが成功すると、config.h.inテンプレートに対応する変数が設定され、config.h. コンパイルのみのテストは、クロスコンパイル環境で正常にテストできます。ただし、コンパイルおよび実行テストは、クロスコンパイル環境では実行できません。

したがって、変換プロセスを開始するには、環境変数CPP、CC、LDおよびその他のツール エイリアスをツールのクロスコンパイラ セット (おそらく のものNDK) に設定してから、 を実行する必要があります./configure。これが完了したらconfig.h、ターゲット環境に合わせて を修正する必要があります。これは、最も重要で最もエラーが発生しやすい手順です。

に関しては、簡単に変換できるAndroid.mk非常に近い形式に従います。とは から生成されるため、Makefile.am無視できます。Makefile.inMakefileMakefile.am

ファイル(バージョン 5.11)の例を挙げると、次のオプションを指定して configure を実行しました。

./configure --host arm-toshiba-linux-androideabi --build x86_64-linux-gnu \
            --prefix=/data/local/ host_alias=arm-linux-androideabi \
           "CFLAGS=--sysroot=~/ndk/platforms/android-8/arch-arm  -Wall -Wextra" \
           "CPPFLAGS=--sysroot=~/ndk/platforms/android-8/arch-arm" \
            CPP=arm-linux-androideabi-cpp

次のステップはsrc/Makefile.am、以下のようにすることでした。

MAGIC = $(pkgdatadir)/magic
lib_LTLIBRARIES = libmagic.la
include_HEADERS = magic.h

bin_PROGRAMS = file

AM_CPPFLAGS = -DMAGIC='"$(MAGIC)"'
AM_CFLAGS = $(CFLAG_VISIBILITY) @WARNINGS@

libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \
        encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \
        funcs.c file.h readelf.h tar.h apptype.c \
        file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h
libmagic_la_LDFLAGS = -no-undefined -version-info 1:0:0
if MINGW
MINGWLIBS = -lgnurx -lshlwapi
else
MINGWLIBS =
endif
libmagic_la_LIBADD = $(LTLIBOBJS) $(MINGWLIBS)

file_SOURCES = file.c
file_LDADD = libmagic.la
CLEANFILES = magic.h
EXTRA_DIST = magic.h.in
HDR= $(top_srcdir)/src/magic.h.in
BUILT_SOURCES = magic.h

magic.h:        ${HDR}
        sed -e "s/X.YY/$$(echo @VERSION@ | tr -d .)/" < ${HDR} > $@

そして、これから作成しますAndroid.mk。

最後の最も重要なステップはconfig.h、ターゲット システムの状態を正確に反映するように を変更することでした。これは、主にconfigure.logを調べ、ヘッダーを調べ、Googleを「呼び出す」ことを含む、回避策を提供できない手動のプロセスになります。この労力の成果はXDAで入手できます。

于 2013-07-05T12:19:14.267 に答える