3

現在、NDKマニフェストファイルからのリソースを含めるのに問題があり、クイックフィックスエラーであると確信しています。大規模なライブラリのプロジェクトとオペレーティングシステム間で共有されるファイルはたくさんあります。したがって、ファイルを他のプロジェクトで最新の状態に保ち、更新が発生するたびに個々のプロジェクトを最新のAPIで更新しないようにするには、多数のネイティブヘッダーファイルとソースコードファイルを相対パスで参照する必要があります。

Eclipse内で、プロジェクトのローカルフォルダー構造内の現在のアプリケーションで必要となるファイルをクリックしてドラッグしました（ファイルをコピーせずに、相対パスを使用します）。

/ projectFolder
   / jni
      / externalProjectFiles
         / src
         /含む

Eclipse内のこのフォルダー構造では、次の構造のAndroid.mkファイルがあります。

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := projectLib

LIBRARY_SRC_FOLDER   := $(wildcard $(LOCAL_PATH)/externalProjectFiles/src/*.cpp)

LOCAL_C_INCLUDES := $(LOCAL_PATH)/externalProjectFiles/include

LOCAL_SRC_FILES :=  projectLibNDK.c
LOCAL_SRC_FILES +=  $(LIBRARY_SRC_FOLDER:$(LOCAL_PATH)/%=%)

LOCAL_LDLIBS    := -L$(SYSROOT)/usr/lib -llog -landroid
LOCAL_CFLAGS    :=  -Wno-multichar -D_ANDROID -DLIBDIR="\"c\"" 
LOCAL_CFLAGS    +=  -DUSE_TCP_LOOPBACK -DMDNS_UDS_SERVERPATH=\"/var/run/mdnsd\" -DIN_LIBRARY -DBUILDING_LIBICONV -DUSE_BONJOUR 
LOCAL_CFLAGS    +=  -DXR_TARGET_ANDROID -DKS_BUILDING_KS -Wno-psabi -Wno-multichar -D_GNU_SOURCE -DHAVE_IPV6=0 -DNOT_HAVE_SA_LEN 
LOCAL_CFLAGS    +=  -DUSES_NETLINK -DHAVE_LINUX -DTARGET_OS_LINUX
LOCAL_CPPFLAGS  :=  -frtti -fexceptions

include $(BUILD_SHARED_LIBRARY)

ただし、projectLibNDC.cに最初のヘッダーを含めようとすると、「そのようなファイルまたはディレクトリはありません」というエラーが出力されます。

#include "externalFile.h"

私が取っているアプローチは可能な解決策ですか？
Android.mkファイル自体にファイルの相対パスを指定する必要がありますか？これは、参照されるファイルのローカルフォルダーを参照するのではなく、もう少し面倒です。

理論的には、この方法でNDKを介してライブラリを作成できるように思えます。しかし、おそらく私はプロジェクトを適切に設定していません。どんな補佐官も役に立ちます。JNIは時々私を振り回す傾向があります。

編集： Eclipse（これは素晴らしいIDEです）には、プロジェクト設定に保持されているリンクされたファイルへの参照の背後に接着剤がないようです。参照されたファイルをプロジェクトにドラッグすると、リンクされたファイルの存在を表すためにそれらのフォルダーに物理ファイルが配置されません。その情報は明らかにプロジェクト設定にのみ保存されます。これはAndroid.mkファイルには役立ちません。

これは、どのファイルまたはmakefileにも、どのファイルが含まれるべきかについての参照がないことを意味します。残念ながら、makefile自体から個別にフォルダとファイルを参照する必要があります。他のプログラマーからのそれらの存在へのヒントとして、プロジェクト内の参照を残すかもしれません。残念ながらそのようにデザインすることはできませんが、それが私がこれまでに受けた結論です。

4

2 に答える 2

2

結局、私が採用することにしたアプローチは、ファイルへの相対パスを個別にmakefileに含めることでした。これは最もクリーンなソリューションではありませんでしたが、機能し、後で使用するための適切な環境を提供しました。

...
LOCAL_C_INCLUDES += $(COMMON_COMPUTATION_PATH)
LOCAL_C_INCLUDES += $(COMMON_DATASET_PATH)
...
LOCAL_SRC_FILES += $(COMMON_COMPUTATION_PATH)/matrixRT.cpp $(COMMON_COMPUTATION_PATH)/multiplRT.cpp
LOCAL_SRC_FILES += $(COMMON_COMPUTATION_PATH)/multiplSqRT.cpp $(COMMON_COMPUTATION_PATH)/multiplSq1978RT.cpp
...

すでにiOSアプリケーション内にリンクされたファイルが含まれていた以前のライブラリから始めて、それらのリソースをEclipseプロジェクト内のローカルフォルダーにドラッグできます。次に、PROJ_LOCから[ファイルへのリンク]を選択します。どちらのプロジェクトも、使用するすべてのファイルへの相対パスが同じであるため、これは魅力のように機能し、必要な個々のファイルを見つけてドロップする必要がなくなりました。

共有ファイルはそれらのディレクトリで必要とされるもののほんの一部であるため、ワイルドカードを使用してソースファイルへの単一のフォルダ参照を作成することで逃げることはできません。ただし、最終的には、モバイルプロジェクトで必要となるファイルを実際に参照できるように、モバイルソフトウェアの組織的なフォルダー構造を要求するのが最善だと思います。

そのため、結局、リンクされたファイルをマニフェストファイルからの参照として使用できませんでした。それがあなたのために働くならば、user1368342はOSレベルのリンクファイルがマニフェストファイルの中から作られそして使われることができると述べました。ただし、複数のOSプラットフォーム間での移植性の理由から、私はそのルートに進まないことにしました。

少なくともこのように設定すると、ユーザーは、ビルド中のプロジェクトライブラリに含まれているリンクされたファイルを確認できます。また、ファイルが変更されて更新されたときに、画面とマニフェストで更新を取得できます。また、プロジェクト内から直接コンパイルすることで発生するエラーを処理する機能もあります。

欠点は、新しいファイルを導入する必要がある場合、単一の場所ではなく、プロジェクトとマニフェストの両方に追加する必要があることです。しかし、それは私にとって許容できる解決策です。うまくいけば、このような問題に遭遇した他の誰もがこのアプローチが役立つと思うでしょう。

于 2013-03-28T11:47:19.483 に答える
1

コメントで述べたように、私はEclipseの参照にも一度問題がありました。代わりに、OSレベルでシンボリックリンクを使用しました。

シンボリックリンクを使用してプロジェクトをバージョン管理すると、問題が発生する可能性があります（ただし、それでも試す価値があると思います）。私の場合、バージョン管理された（そしてすべての物理ファイルを含む）メインプロジェクトがあり、シンボリックリンクを使用してバージョン管理されていないライブラリをコンパイルしました。

于 2013-03-27T14:18:23.170 に答える