Cómo escribir/depurar Android.mk para la biblioteca estática de NDK?

Question

Estoy tratando de construir una biblioteca estática utilizando el último Android NDK (r5) y no estoy teniendo suerte. He podido construir y ejecutar las muestras (por ejemplo, HelloJni) sin ningún problema, pero comenzar un nuevo proyecto desde 'cero' ha sido una historia diferente.

Para este experimento, intento crear libpng. Mi estructura de carpetas tiene este aspecto:

root 
| 
+--- jni 
     | 
     +---- Android.mk (one line: "include $(call all-subdir-makefiles)") 
     | 
     +---- png 
      | 
      +---- Android.mk (see below) 
      | 
      +---- { a bunch of .c and .h files) 

Así que tengo dos Android.mks. Uno para construir todos los subproyectos y otro para el subproyecto libpng. root/JNI/png/Android.mk se ve así:

configuración

LOCAL_PATH := $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE := png 
MODULE_PATH := $LOCAL_PATH 
LOCAL_SRC_FILES := $(wildcard $(LOCAL_PATH)/*.c) 
LOCAL_C_INCLUDES := $(wildcard $(LOCAL_PATH)/*.h) 

LOCAL_INTERMEDIATE_TARGETS += junk 
junk: 
    echo $(LOCAL_SRC_FILES) 

include $(BUILD_STATIC_LIBRARY) 

Esta construcción parece no hacer nada (es decir, funcionando NDK-construir a partir de la carpeta raíz no hace nada, incluso después de una NDK-construir limpia). Una ejecución detallada (ndk-build V = 1) muestra algunas llamadas rm -f (eliminando carpetas inexistentes) pero nada relacionado con el proyecto o subproyecto.

Estoy bastante interesado en por qué esta secuencia de comandos de construcción está fallando, pero el proceso debería haber sido trivial, así que estoy seguro de que no es nada terriblemente interesante. Estoy mucho más interesado en cómo podría comenzar a atacar errores de compilación por mi cuenta. La llamada de eco en el guión anterior nunca se ve afectada: no tengo idea de cómo determinar qué valores son o por qué se salta el subproyecto. ¿Alguien ha encontrado una forma de saber qué es el sistema de compilación intentando hacer?

También me interesaría saber si hay documentos para estas herramientas o si solo son un puñado de archivos de texto en la carpeta docs del NDK. He intentado resolver esto copiando fragmentos de Android.mk aleatorios que he encontrado al buscar en Google, pero solo los pocos comandos utilizados en las muestras simples de NDK parecen estar documentados, por lo que la experiencia en realidad acaba de plantear nuevas preguntas.

Answer 1

Recomendaría deshacerse de MODULE_PATH y no tratar de usar el comodín: realmente no he visto que funcione bien.

LOCAL_PATH := $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE := png 
LOCAL_SRC_FILES := pngget.c pngread.c pngrutil.c pngtrans.c pngwtran.c png.c pngmem.c pngrio.c pngset.c pngwio.c pngwutil.c pngerror.c pngpread.c pngrtran.c pngwrite.c 
LOCAL_C_INCLUDES := png.h pngconf.h pngpriv.h 

include $(BUILD_STATIC_LIBRARY) 

Además, hay algunos graves mágica ruta no he descifrado completamente: Eclipse alguna manera hace lo correcto, pero conseguir que salte por los aros adecuados desde la línea de comandos todavía es impredecible para mí.

EDITAR: por lo que estaba moderadamente interesado en entender esto, ya que ha pasado un tiempo desde que jugué con el NDK. Cuando utilizo el archivo original no se compila, pero cuando puse el código fuente png en el directorio jni y luego usan este archivo Android.mk:

LOCAL_PATH := $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE := png 
LOCAL_SRC_FILES := pngget.c pngread.c pngrutil.c pngtrans.c pngwtran.c png.c pngmem.c pngrio.c pngset.c pngwio.c pngwutil.c pngerror.c pngpread.c pngrtran.c pngwrite.c 
LOCAL_C_INCLUDES := png.h pngconf.h pngpriv.h 

include $(BUILD_STATIC_LIBRARY) 

include $(CLEAR_VARS) 
LOCAL_MODULE := png2 
LOCAL_STATIC_LIBRARIES := png 

include $(BUILD_SHARED_LIBRARY) 

se construyó tanto la libpng.a y libpng2. entonces en la carpeta obj/local/armeabi. Supongo que simplemente no creará una biblioteca estática si no hay dependencia.

Answer 2

Me he estado golpeando en la cabeza con este problema durante las últimas dos horas, y esta publicación me ayudó a resolverlo. En lugar de agregar una dependencia ficticia, simplemente invoque ndk-build (que es solo una envoltura delgada sobre make) como "ndk-build png".

Answer 3

Descubrí que cuando agregué una biblioteca compartida "ficticia" como se describe en la edición, la .a (que encontré en obj /, lo que implica que era un detalle interno) no contenía ninguno de los archivos .o Quise.

Además, el .so volvió a compilar todos los archivos que se habrían creado para la biblioteca estática. Entonces, tenía sentido que el .a estuviera vacío.

Lo que me ayudó fue agregar una línea APP_MODULES a mi Application.mk, como se describe en Cannot build static library with Android NDK R8. Es probable que desee una Application.mk de todos modos, ya que contiene otras configuraciones importantes para su lib estática, como APP_STL, APP_PLATFORM, APP_ABI, etc.