2016-04-22 20 views
11

Ich habe ein natives Projekt, dass in Frustration mit dem make-System habe ich arbeiten, indem ich einfach den ganzen Code vor vielen Jahren zusammen jammen. Ich habe versucht, das Projekt ordentlich in Großprojekte zu portieren, aber das ist immer noch eine Katastrophe, 2,5 Jahre später. Ich versuche jetzt, das Android.mk-System innerhalb des reorganisierten (für groß-experimentelle) Projekts zu arbeiten.Android ndk verschachtelte Module

Hier ist die Organisation:

  • jpeg (Voll nativ)
  • Prozessor (voll nativen, abhängig von jpeg)
  • Bibliothek (JNI, abhängig von Prozessor und jpeg)

module 
-jni (contains Application.mk, Android.mk) 
-jpeg 
--src 
---main 
----jni 
-----Android.mk (and source co-located) 
-processor 
--src 
----main 
-----jni 
------Android.mk 
------/processor(source) 
-library 
--src 
----main 
-----java 
-----jni 
-----Android.mk (and source co-located) 

Ich weiß, ich könnte dies platt machen, wenn Ich benutze die make-Dateien, aber ich glaube, irgendwann im Jahr 2020 wird Android Studio wirklich native unterstützen, so dass ich dachte, ich würde das aktuelle Projektformat behalten.

Hier sind meine Make-Dateien:

Modul/jni:

LOCAL_PATH := $(call my-dir) 
STARTUP_DIR := $(LOCAL_PATH) 

include $(STARTUP_DIR)/../jpeg/src/main/jni/Android.mk 
include $(STARTUP_DIR)/../processor/src/main/jni/Android.mk 
include $(STARTUP_DIR)/../library/src/main/jni/Android.mk 

include $(CLEAR_VARS) 

jpeg/jni:

LOCAL_PATH:= $(call my-dir) 
include $(CLEAR_VARS) 

LOCAL_ARM_MODE := arm 

LOCAL_SRC_FILES := [truncated] 

LOCAL_CFLAGS += -DAVOID_TABLES 
LOCAL_CFLAGS += -O3 -fstrict-aliasing -fprefetch-loop-arrays 
#LOCAL_CFLAGS += -march=armv6j 

# enable tile based decode 
LOCAL_CFLAGS += -DANDROID_TILE_BASED_DECODE 

ifeq ($(TARGET_ARCH_VARIANT),x86-atom) 
    LOCAL_CFLAGS += -DANDROID_INTELSSE2_IDCT 
    LOCAL_SRC_FILES += jidctintelsse.c 
endif 

# enable armv6 idct assembly 
ifeq ($(strip $(TARGET_ARCH)),arm) 
    LOCAL_CFLAGS += -DANDROID_ARMV6_IDCT 
endif 

# use mips assembler IDCT implementation if MIPS DSP-ASE is present 
ifeq ($(strip $(TARGET_ARCH)),mips) 
    ifeq ($(strip $(ARCH_MIPS_HAS_DSP)),true) 
    LOCAL_CFLAGS += -DANDROID_MIPS_IDCT 
    LOCAL_SRC_FILES += \ 
     mips_jidctfst.c \ 
     mips_idct_le.S 
    endif 
endif 

LOCAL_MODULE := libjpeg 

include $(BUILD_STATIC_LIBRARY) 

Prozessor/jni

LOCAL_PATH := $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_CFLAGS += -DUSE_JPEG 
LOCAL_STATIC_LIBRARIES += libjpeg 
LOCAL_C_INCLUDES += $(LOCAL_PATH)/../../../../jpeg/src/main/jni 

LOCAL_MODULE  := processor 

LOCAL_SRC_FILES := [truncated] 

LOCAL_C_INCLUDES += [truncated] 

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/processor/include 
LOCAL_LDLIBS += -lz 

include $(BUILD_SHARED_LIBRARY) 

Wenn ich ndk-build starte, wird es jpeg erfolgreich erstellen, wenn es zum Prozessoraufbau kommt. Es wird jedoch nicht jeden Code Referenzierung JPEG (in-Prozessor) mit undefinierten Referenzen zu bauen, wie:

undefined reference to `jpeg_std_error (jpeg_error_mgr *)‘

Ich habe das Gefühl, ich mache etwas falsch beim Einrichten der Eltern Android.mk, so dass LOCAL_STATIC_LIBRARIES += libjpeg nicht korrekt importiert wird. Wer weiß, was ich hier falsch mache?

Antwort

6

Es stellte sich heraus, dass ich den falschen JPEG-Header, der nicht extern "C" hatte, um mit Namen Mangling in C++ zu helfen zog. Das Beheben des Headers behebt das Problem.

Darüber hinaus musste ich die Ordnerstruktur als geschachtelte NDK reorganisieren ist ein Albtraum, wenn alle Projekte nicht unter jni fallen. Es wird anfangen, LOCAL_PATH, Wildcards und im Grunde jeden relativen Pfad zu verändern.

+0

Was meinst du mit "gezogen"? – rmtheis

+1

Ich benutzte eine Androide kompatible jpeg-turbo Bibliothek, der ich das externe "c" hinzufügte, aber Jahre später vergaß ich völlig, den richtigen Zweig zu ergreifen, als ich versuchte, zu grillen-experimentell zu portieren. Das meinte ich mit "falsch gemacht" – Anthony