2016-04-11 1 views
1

J'ai une application native Android qui se construit pour plate-forme x86, armeabi et armeabi-v7a. Maintenant, selon que la plate-forme est x86 ou arm, j'ai besoin d'exécuter le script en conséquence avec les arguments correspondants afin que les variables d'environnement de l'outil tiers appropriées soient définies. J'ai essayé de faire ci-dessous:Android exécuter shell script via makefile pour chaque plate-forme mentionnée dans APP_ABI

.o.cpp: 
     ifeq ($(TARGET_ARCH),x86) 
      $(info $(shell ($(CACHE_LOCAL_PATH_MAIN)/setup_tool.sh x86))) 
     else 
      $(info $(shell ($(CACHE_LOCAL_PATH_MAIN)/setup_tool.sh arm))) 
     endif 

Mais le problème est, lorsque le makefile est analysé, ces scripts sont exécutés dans la phase initiale elle-même 3 fois et non avant la compilation de chaque plate-forme commence. Existe-t-il un moyen d'obtenir cette correction afin que le script soit exécuté juste avant que la compilation pour chaque plate-forme commence? Merci.

MIS À JOUR avec le fichier Android.mk:

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

LOCAL_C_INCLUDES := \ <path_to_include_files> 

LOCAL_CFLAGS := <cflags included here> 

LOCAL_LDLIBS := <ld libs included here> 

LOCAL_SRC_FILES := <src files to be compiled> 

LOCAL_MODULE := <module_name> 

LOCAL_SHARED_LIBRARIES := <shared libs on which we are dependent> 

LOCAL_WHOLE_STATIC_LIBRARIES := <static libs> 

include $(BUILD_SHARED_LIBRARY) 
+0

Si vous avez ** Android.mk **, la meilleure pratique consiste à y mettre toutes les déclarations make pertinentes. Rappelez-vous que ** Android.mk ** est juste un makefile, et suit les mêmes règles de syntaxe et cycle de vie qu'un makefile habituel, seulement il est inclus dans le framework sophistiqué de NDK, et utilisé plusieurs fois (une fois par ABI) et définit la bibliothèque native comme cible. Vous pouvez donc exécuter 'setup_tool.sh' en tant que dépendance de la bibliothèque native. –

+0

Oui, nous utilisons Android.mk. Pouvez-vous s'il vous plait prendre soin de partager comment j'ajoute un script shell en tant que dépendance pour l'objet partagé que je vise? Le format de construction du .so ressemble à celui que j'ai ajouté à ma question. –

+0

Quand avez-vous l'intention d'utiliser ces variables environnementales? Dans l'exécution de cette règle, ou dans une autre règle? – Beta

Répondre

1

Une solution simple, mais pas élégant se présente comme suit:

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

LOCAL_C_INCLUDES := \ <path_to_include_files> 

LOCAL_CFLAGS := <cflags included here> 

LOCAL_LDLIBS := <ld libs included here> 

ifeq ($(TARGET_ARCH),x86) 
    LOCAL_SRC_FILES := /tmp/dummy.x86.c 
else 
    LOCAL_SRC_FILES := /tmp/dummy.arm.c 
     $(info $(shell ($(CACHE_LOCAL_PATH_MAIN)/setup_tool.sh arm))) 
endif 

LOCAL_SRC_FILES += <src files to be compiled> 

LOCAL_MODULE := <module_name> 

LOCAL_SHARED_LIBRARIES := <shared libs on which we are dependent> 

LOCAL_WHOLE_STATIC_LIBRARIES := <static libs> 

include $(BUILD_SHARED_LIBRARY) 

.PHONY: /tmp/dummy.x86.c /tmp/dummy.arm.c 

/tmp/dummy.x86.c: 
     $(CACHE_LOCAL_PATH_MAIN)/setup_tool.sh x86 
     @touch [email protected] 

/tmp/dummy.arm.c: 
     $(CACHE_LOCAL_PATH_MAIN)/setup_tool.sh arm 
     @touch [email protected] 

Une mise en garde: ce reliera la bibliothèque à chaque fois, même si rien n'a changé. Vous pouvez définir des dépendances avec soin au lieu de .PHONY pour améliorer cela.

+0

Bravo !!, il semble exécuter le script une fois pour la construction du bras et une fois pour le build x86 (ce qui devrait être suffisant). Je peux probablement ajouter les nouveaux fichiers générés à '.gitignore'. J'essaie de trouver un autre problème après ces changements. Une fois que le script shell est exécuté et que les variables d'environnement sont définies, même après avoir généré le script shell, ces variables n'ont pas été définies dans le script shell principal à partir duquel j'ai déclenché la compilation. PATH' n'a pas été mis à jour et c'est ce que j'étudie actuellement. –

+0

pour éviter les problèmes avec GIT, vous pouvez mettre le fichier en dehors de vos répertoires contrôlés par la version, et utiliser le chemin absolu de ces fichiers partout. –

+0

Vous avez raison, ** make ** ouvre un shell secondaire qui ne se propage pas au shell utilisé pour la compilation. Le hack ci-dessus est utile si le script copie des fichiers dépendants du processeur d'un endroit à l'autre ou effectue d'autres changements globaux. Si votre 'setup_tool.sh' prépare CFLAGS etc., vous avez besoin d'un techinque différent. –