2011-04-27 1 views
7

J'essaye de construire une bibliothèque statique en utilisant le dernier Android NDK (r5) et je n'ai pas de chance. J'ai été capable de construire et d'exécuter les échantillons (par exemple, HelloJni) sans aucun problème, mais démarrer un nouveau projet à partir de 'scratch' a été une histoire différente.Comment écrire/déboguer Android.mk pour la bibliothèque statique NDK?

Pour cette expérience, j'essaie de construire libpng. Ma structure de dossiers ressemble à ceci:

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

J'ai donc deux Android.mk. Un pour la construction de tous les sous-projets et un pour le sous-projet libpng. root/JNI/.png/Android.mk ressemble à ceci:

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) 

Cette configuration de construction semble ne rien faire (à savoir en cours d'exécution NDK-construire à partir du dossier racine ne fait rien, même après une NDK-construction propre). Une exécution verbeuse (ndk-build V = 1) affiche certains appels rm -f (suppression de dossiers inexistants) mais aucun lien avec le projet ou le sous-projet.

Je suis très intéressé par la raison pour laquelle ce script de construction échoue, mais le processus aurait dû être trivial, donc je suis sûr que ce n'est rien terriblement intéressant. Je suis beaucoup plus intéressé par la façon dont je pourrais commencer à attaquer les bugs de build par moi-même. L'appel d'écho dans le script ci-dessus n'est jamais atteint - je n'ai aucune idée de la façon de déterminer quelles sont les valeurs ou pourquoi il ignore le sous-projet. Quelqu'un at-il trouvé un moyen de savoir ce que le système de construction est en essayant à faire?

Je serais également intéressé de savoir s'il existe des documents pour ces outils ou si c'est juste la poignée de fichiers texte dans le dossier docs du NDK? J'ai essayé de résoudre ce problème en copiant des morceaux de Android.mk que j'ai trouvés à partir de googler mais seulement les quelques commandes utilisées dans les exemples NDK simples semblent être documentées, donc l'expérience a en fait soulevé de nouvelles questions.

Répondre

9

Je recommande de se débarrasser de MODULE_PATH et ne pas essayer d'utiliser le caractère générique: Je n'ai pas vraiment vu ce travail 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) 

De plus, il y a quelque chose de magique de chemin sérieux, je ne l'ai pas entièrement déchiffré: en quelque sorte Eclipse fait la bonne chose, mais l'obtenir pour sauter à travers les cerceaux appropriés de la ligne de commande est toujours frappé ou manquer pour moi.

EDIT: donc était modérément intéressé à comprendre cela, comme cela fait un moment que j'ai joué avec le NDK. Lorsque j'utilise le fichier d'origine, il ne compile pas, mais lorsque je place le code source .png dans le répertoire jni puis utilisez ce fichier 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) 

a construit à la fois la libpng.a et libpng2. donc dans le dossier obj/local/armeabi. Je suppose qu'il ne construira tout simplement pas une bibliothèque statique s'il n'y a pas de dépendance.

+0

Merci. J'ai essayé cela et cela n'a pas changé le comportement (ndk-build est toujours un no-op). J'ai également essayé d'enlever LOCAL_C_INCLUDES, car je ne peux pas dire pourquoi cela serait utilisé. Pas de chance. Il semble que vous suggérez que j'utilise eclipse pour générer ce fichier mk? Je ne savais pas que tu pouvais faire ça. Je pourrais être en mesure d'utiliser cela au lieu d'instructions sur la façon de déboguer les fichiers .mk. Pouvez-vous me montrer des instructions sur la façon de faire cela? – Dave

+0

Odd: désolé, cela n'a pas fonctionné. Le fichier de référence original a été généré à la main, mais construit par Eclipse à moins que je me rappelle mal. Je vais essayer de le construire moi-même. Une chose à noter: si vous faites cela sur Windows, vous devez vous assurer qu'il n'y a pas d'espaces dans vos chemins, comme d'une manière ou d'une autre après plus d'une décennie Cygwin STILL ne peut pas gérer les espaces correctement (pas que le studio visuel ddk fait un travail sensationnel, donc ça peut être juste du vent de Windows). – Femi

+0

Je vais essayer de mettre au rebut ma structure de dossiers et d'utiliser votre fichier verbatim. Mais la question originale, sur la façon de déboguer ces fichiers .mk, serait toujours valable. FYI, je suis sur un Mac ... – Dave

1

Je me suis battu la tête avec ce problème au cours des deux dernières heures, et ce message a aidé à le résoudre. Plutôt que d'ajouter une dépendance fictive, appelez simplement ndk-build (qui est juste un fin wrapper sur make) en tant que "ndk-build png".

0

J'ai trouvé que lorsque j'ai ajouté une bibliothèque partagée "fictive" comme décrit dans l'édition, le .a (que j'ai trouvé dans obj /, ce qui implique qu'il s'agissait d'un détail interne) ne contenait aucun des fichiers. J'ai voulu.

En outre, le fichier .so a recompilé tous les fichiers qui auraient été créés pour la bibliothèque statique. Il était donc logique que le .a soit vide.

Ce qui m'a aidé était d'ajouter une ligne APP_MODULES à mon Application.mk, comme décrit dans Cannot build static library with Android NDK R8. Vous voulez probablement un Application.mk de toute façon, car il contient d'autres paramètres importants pour votre bibliothèque statique, comme APP_STL, APP_PLATFORM, APP_ABI, etc.

Questions connexes