Comment incorporer un fichier make existant avec Android NDK

Donc j'ai une énorme C existant projet que j'ai placé dans $PROJECT/jni répertoire. Ce projet est normalement fait en exécutant un script de configuration qui crée les fichiers "Makefile" qui permet au projet d'être compilé via make.

Ce projet est assez grand et a beaucoup de répertoires contenant les fichiers source et les fichiers d'en-tête.

Je suppose que je manque fondamental de la compréhension de la façon dont Android.mk est censé fonctionner. Est-il censé remplacer le configurer et makefile qui est actuellement utilisé pour compiler le projet? Ou serais-je en incorporant le makefile à partir de mon script de configuration dans le Android.mk? Les exemples qu'ils fournissent sont plutôt banal, avec seulement quelques fichiers sources. Mon jni répertoire ressemble plus à:

jni/
  folder1/subfolder1
  folder1/subfolder2
  folder1/source
  folder2/source
  .....
  foldern/source
  configure/
  configure/configure.sh
  Makefile
  Android.mk

Les makefiles générés assez vaste (une bonne quantité de configuration et il y en a un dans chaque répertoire) donc je suis un peu perdu pour l'approche de la ce.

EDIT:

Le problème majeur est que les exemples fournis avec le NDK sont triviales exemples. Ils ont 3-5 fichiers source dans le haut niveau jni répertoire. Mon problème est que c'est un énorme projet avec une configuration complexe avec 4 dossiers de niveau supérieur chacune avec de nombreux sous-répertoires. Je ne peux pas il suffit de déplacer la source dans la jni dossier et exécutez le ndk compilateur.

source d'informationauteur thatidiotguy

android android-ndk c makefile

13

Pour répondre à votre question, oui Android.mk est Android système de construction. Google à peine mentionne que la "langue" de ce fichier est mis en œuvre comme GNU faire des macros. Les docs voulez-vous de décrire votre projet en termes de ces macros. Ils traitent tous les grungy la cross-compilation de détails. Je suis sûr que Google a pris cette approche pour améliorer l'avant de la portabilité de Android.mk fichiers que les outils de développement évoluer.

Le résultat est que (et je sais que vous ne voulez pas entendre cela), la meilleure réponse est sans doute pour écrire un NDK Android.mk pour votre grand projet à partir de zéro.

Cet article porte sur les mêmes observations que j'ai faite le portage d'une bibliothèque d'environ 800 fichiers et 300k SLOC. Malheureusement, j'ai brûlé près de deux semaines pour atteindre la même conclusion: la Cross-compilation provoque au moins certains configure l'échec de scripts (résultat erroné config.h fichiers). J'ai "inventé" à peu près les mêmes techniques qu'il utilise dans l'article. Mais même après que j'ai obtenu une nouvelle version, la bibliothèque statique ne fonctionne pas complètement. Heures de débogage en résille aucune information utile. [Mise en garde: je ne suis pas le genre de configuration des outils de l'expert. Un gourou sans doute aurait-elle remarqué mon erreur. Il en va.] Il m'a fallu quelques jours pour créer un nettoyage Android.mk. La bibliothèque résultante couru tous les tests de la première fois. Et il a porté proprement par plusieurs tours d'outils de développement.

Malheureusement, la construction d'une bibliothèque qui utilise configure sans l'auto tools signifie la construction de votre propre config.h par la main pour l'environnement cible. Cela pourrait ne pas être aussi mauvais que cela puisse paraître. IME les systèmes ont tendance à définir beaucoup plus dans leur configure environnements qu'ils utilisent réellement. Obtenir une idée claire de dépendances réels peuvent rembourser le pénible effort au cours de refactoring.

Le résumé de la déclaration de l'article dit tout:

Autotools est bonne que sur des systèmes GNU et de l'utiliser pour la compilation croisée peut être vraiment pénible, de la confusion, de commettre des erreurs, voire impossible. La méthode décrite ici est un hack et doit être utilisé à vos propres risques.

Désolé je n'ai pas plus de la suggestion positive.
5

Ma réponse qui fonctionne le mieux en tandem avec Gène's réponse.

./configure'création du fichier de configuration est basée sur la compilation (et éventuellement en cours d'exécution) de petits extraits de C code pour chaque test. Le succès de chacun des jeux de test d'une variable correspondante dans le config.h.in modèle pour créer le config.h. La compilation seuls les tests peuvent être testées avec succès dans un cross-compiler pour l'environnement. Cependant, la compilation et exécuter les tests sont impossibles à exécuter dans un cross-compiler pour l'environnement.

Ainsi, pour démarrer le processus de conversion, vous devez définir les variables d'environnement CPP,CC,LD et d'autres outil de alias pour le cross-compilateur ensemble d'outils (probablement celles de la NDK), puis exécutez ./configure. Une fois que c'est fait, alors vous aurez besoin pour corriger la config.h pour correspondre à votre environnement cible. C'est votre plus critiques et les plus enclins à faire des erreurs étape.

Comme pour le Android.mkil suit un format assez proche de Makefile.am qui peut être facilement converti en elle. Vous pouvez ignorer le Makefile.in et la Makefilecar ils sont générés à partir de la Makefile.am.

Pour prendre un exemple de fichier (version 5.11), j'ai couru configure avec les options suivantes,
```
./configure --host arm-toshiba-linux-androideabi --build x86_64-linux-gnu \
            --prefix=/data/local/ host_alias=arm-linux-androideabi \
           "CFLAGS=--sysroot=~/ndk/platforms/android-8/arch-arm  -Wall -Wextra" \
           "CPPFLAGS=--sysroot=~/ndk/platforms/android-8/arch-arm" \
            CPP=arm-linux-androideabi-cpp
```
La prochaine étape a été de prendre la src/Makefile.am comme ci-dessous:
```
MAGIC = $(pkgdatadir)/magic
lib_LTLIBRARIES = libmagic.la
include_HEADERS = magic.h

bin_PROGRAMS = file

AM_CPPFLAGS = -DMAGIC='"$(MAGIC)"'
AM_CFLAGS = $(CFLAG_VISIBILITY) @WARNINGS@

libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \
        encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \
        funcs.c file.h readelf.h tar.h apptype.c \
        file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h
libmagic_la_LDFLAGS = -no-undefined -version-info 1:0:0
if MINGW
MINGWLIBS = -lgnurx -lshlwapi
else
MINGWLIBS =
endif
libmagic_la_LIBADD = $(LTLIBOBJS) $(MINGWLIBS)

file_SOURCES = file.c
file_LDADD = libmagic.la
CLEANFILES = magic.h
EXTRA_DIST = magic.h.in
HDR= $(top_srcdir)/src/magic.h.in
BUILT_SOURCES = magic.h

magic.h:        ${HDR}
        sed -e "s/X.YY/$$(echo @VERSION@ | tr -d .)/" < ${HDR} > $@
```
Et de créer de la Android.mk.

La dernière étape et la plus importante a été de modifier le config.h afin de refléter avec précision l'état du système cible. Ce sera un processus manuel qui je ne peux pas donner une solution de contournement pour, impliquant principalement à la recherche dans les configurer.journal, en regardant dans les en-têtes et "invocation" de Google. Les fruits de ce travail sont disponibles sur XDA.
3

Voici une solution pour faire les choses dans l'autre sens: bâtiment
à la fois de la bibliothèque externe et le package Android à partir de la norme Makefiles.

Comme une condition préalable, vous devez installer tout le nécessaire pour faire de la ligne de commande
Développement Android:
- Autonome de la chaîne, consultez la documentation incluse dans le Android NDK;
- ant.
La structure de l'exemple: un répertoire pour la bibliothèque externe
et un répertoire pour l'Androïde sources au même niveau avec un Makefile
dans chaque répertoire, et un niveau supérieur, récursive Makefile:
```
Makefile
mylib/
    Makefile
android/
    Makefile
```
La mylib/Makefile construit une bibliothèque statique:
```
AR=/path/to/standalone/bin/arm-linux-androideabi-ar
CC=/path/to/standalone/bin/arm-linux-androideabi-gcc

libmylib.a: mylib.o
    $(AR) rcs libmylib.a mylib.o

mylib.o: mylib.c
    $(CC) -c mylib.c -o mylib.o
```
La android/Makefile est de fournir des règles pour construire le package Android:
- nous avons besoin d'une dépendance à copier mylib quand il est modifié;
- nous sommes à l'aide d'un jni/ndkmake.c fichier à encapsuler les appels à mylib et de fournir android choses spécifiques;
- le package android dépend des sources Java et sur la bibliothèque partagée.
Le Makefile fournit deux cibles: release (par défaut) et debug pour créer un package de la version ou de débogage.
```
NDK_BUILD=/path/to/ndk-build
JAVASRC=src/com/example/ndkmake/NdkMake.java

release: bin/NdkMake-release-unsigned.apk

debug: bin/NdkMake-debug.apk

bin/NdkMake-release-unsigned.apk: libs/armeabi/libndkmake.so $(JAVASRC)
ant release

bin/NdkMake-debug.apk: libs/armeabi/libndkmake.so $(JAVASRC)
ant debug

libs/armeabi/libndkmake.so: jni/ndkmake.c jni/libmylib.a
$(NDK_BUILD)

jni/libmylib.a: ../mylib/libmylib.a
cp ../mylib/libmylib.a jni/libmylib.a
```
La Android.mk fichier fournit les règles pour y inclure la bibliothèque statique dans la construction, comme prêtes à l'emploi.
Nous sommes, y compris les en-têtes de la mylib de la bibliothèque à l'aide de LOCAL_EXPORT_C_INCLUDES.
```
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := ndkmake
LOCAL_SRC_FILES := ndkmake.c
LOCAL_STATIC_LIBRARIES := mylib-prebuilt
include $(BUILD_SHARED_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := mylib-prebuilt
LOCAL_SRC_FILES := libmylib.a
LOCAL_EXPORT_C_INCLUDES := ../mylib/
include $(PREBUILT_STATIC_LIBRARY)
```
Maintenant nous avons seulement besoin d'un haut niveau Makefile pour construire les deux sous-répertoires:
```
all: libmylib package

libmylib:
    cd mylib && $(MAKE)

package:
    cd android && $(MAKE)
```
Tout changement à la bibliothèque, à la jni sources ou les sources Java sera le déclencheur d'une reconstruction
de l'emballage.

Vous devez vous connecter pour publier un commentaire.