Android.MK

In questa pagina viene descritta la sintassi del file di build Android.mk utilizzato da ndk-build.

Panoramica

Il file Android.mk si trova in una sottodirectory della proprietà jni/ del progetto e descrive le origini e le librerie condivise nel sistema di compilazione. Si tratta in realtà di un piccolo frammento del file di makefile GNU che il sistema di compilazione analizza una volta o altro ancora. Il file Android.mk è utile per definire impostazioni a livello di progetto che Application.mk, il sistema di compilazione e le variabili di ambiente lasciano non definito. Può anche sostituire le impostazioni a livello di progetto per moduli specifici.

La sintassi dell'Android.mk consente di raggruppare le origini in moduli. Un modulo è una libreria statica, una libreria condivisa o una libreria indipendente eseguibile. Puoi definire uno o più moduli in ogni file Android.mk e puoi utilizzare lo stesso file di origine in più moduli. Solo il sistema di compilazione delle librerie condivise nel pacchetto dell'applicazione. Inoltre, il traffico delle librerie possono generare librerie condivise.

Oltre alla pacchettizzazione delle librerie, il sistema di compilazione gestisce una varietà di altri i dettagli per te. Ad esempio, non è necessario elencare file di intestazione o delle dipendenze tra i file generati nel file Android.mk. La build NDK il sistema elabora automaticamente queste relazioni. Di conseguenza, dovrebbe poter beneficiare del supporto di una nuova catena di strumenti/piattaforma nel futuro NDK senza dover modificare il file Android.mk.

La sintassi di questo file è molto simile a quella utilizzata nei file Android.mk distribuiti con l'intero progetto open source Android. Mentre il sistema di compilazione che l'implementazione è diversa, la loro somiglianza è una scelta intenzionale decisione di progettazione finalizzata a semplificare il riutilizzo da parte degli sviluppatori di applicazioni per le librerie esterne.

Nozioni di base

Prima di esplorare la sintassi in dettaglio, è utile iniziare con la comprensione le nozioni di base su cosa contiene un file Android.mk. In questa sezione vengono utilizzati i Android.mk nell'esempio Hello-JNI a questo scopo, che spiega il ruolo riprodotta da ogni riga del file.

Un file Android.mk deve iniziare a definire la variabile LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

Questa variabile indica la posizione dei file di origine all'interno albero di Natale. In questo caso, la funzione macro my-dir, fornita dal sistema di compilazione, restituisce il percorso della directory corrente (la directory contenente Android.mk file stesso).

La riga successiva dichiara la variabile CLEAR_VARS, il cui valore è il sistema di compilazione fornisce.

include $(CLEAR_VARS)

La variabile CLEAR_VARS punta a uno speciale Makefile GNU che cancella molti LOCAL_XXX variabili per te, ad esempio LOCAL_MODULE, LOCAL_SRC_FILES e LOCAL_STATIC_LIBRARIES. Tieni presente che questa operazione non consente di cancellare LOCAL_PATH. Questo deve conservare il suo valore perché il sistema analizza tutti i file di controllo di build in un singolo GNU, in cui tutte le variabili sono globali. Devi (ri)dichiari questa variabile prima di descrivere ogni modulo.

La variabile LOCAL_MODULE archivia quindi il nome del modulo che vuoi creare. Utilizza questa variabile una volta per modulo nella tua applicazione.

LOCAL_MODULE := hello-jni

Ciascun nome di modulo deve essere univoco e non deve contenere spazi. Il sistema di compilazione, quando genera il file finale della libreria condivisa, aggiunge automaticamente prefisso e suffisso al nome che assegni a LOCAL_MODULE. Ad esempio: l'esempio riportato sopra genera la generazione di una libreria chiamata libhello-jni.so.

Nella riga successiva sono elencati i file di origine, con gli spazi che delimitano più file:

LOCAL_SRC_FILES := hello-jni.c

La variabile LOCAL_SRC_FILES deve contenere un elenco di file di origine C e/o C++ in un modulo.

L'ultima riga consente al sistema di collegare tutti gli elementi:

include $(BUILD_SHARED_LIBRARY)

La variabile BUILD_SHARED_LIBRARY rimanda a uno script GNU Makefile che raccoglie tutte le informazioni che hai definito nelle variabili LOCAL_XXX a partire dalla include recente. Questo script determina cosa creare e come farlo.

Ci sono esempi più complessi nelle directory di esempio, con Android.mk file che puoi esaminare. Inoltre, Esempio: attività nativa fornisce una spiegazione dettagliata del file Android.mk di questo campione. Infine, Variabili e macro fornisce ulteriori informazioni sulle variabili di questo .

Variabili e macro

Il sistema di compilazione fornisce molte possibili variabili da utilizzare nel file Android.mk. Molte di queste variabili sono fornite con valori preassegnati. Altre, tu assegna.

Oltre a queste variabili, puoi anche definirne di arbitrarie. In questo caso, mantieni tieni presente che il sistema di build NDK riserva i seguenti nomi di variabili:

• Nomi che iniziano con LOCAL_, ad esempio LOCAL_MODULE.
• Nomi che iniziano con PRIVATE_, NDK_ o APP. Il sistema di compilazione utilizza internamente.
• Nomi in minuscolo, ad esempio my-dir. Il sistema di compilazione li utilizza internamente, beh.

Se devi definire le tue variabili di convenienza in un file Android.mk, consiglia di anteporre MY_ ai nomi.

Variabili di inclusione definite da NDK

Questa sezione illustra le variabili GNU Make definite dal sistema di compilazione prima di analizzare il file Android.mk. In determinate circostanze, l'NDK potrebbe analizzare più volte il file Android.mk, utilizzando una definizione diversa per alcune di queste variabili.

CANCELLA_VAR

Questa variabile punta a uno script di build che non definisce quasi tutti i campi LOCAL_XXX variabili elencate nella sezione "Variabili definite dallo sviluppatore" di seguito. Usa questa per includere questo script prima di descrivere un nuovo modulo. La sintassi per è:

include $(CLEAR_VARS)

CREA_ESECUZIONE

Questa variabile punta a uno script di build che raccoglie tutte le informazioni il modulo che hai fornito nelle variabili LOCAL_XXX e determina come creare un eseguibile di destinazione dalle origini elencate. Tieni presente che l'utilizzo di lo script richiede che tu abbia già assegnato valori a LOCAL_MODULE e Almeno LOCAL_SRC_FILES (per ulteriori informazioni su queste variabili, consulta variabili di descrizione del modulo).

La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_EXECUTABLE)

CREA_LIBRERIA_CONDIVISA

Questa variabile punta a uno script di build che raccoglie tutte le informazioni il modulo che hai fornito nelle variabili LOCAL_XXX e determina come Creare una libreria condivisa di destinazione dalle origini elencate. Tieni presente che l'utilizzo di lo script richiede che tu abbia già assegnato valori a LOCAL_MODULE e Almeno LOCAL_SRC_FILES (per ulteriori informazioni su queste variabili, consulta variabili di descrizione del modulo).

La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_SHARED_LIBRARY)

Una variabile della libreria condivisa fa sì che il sistema di compilazione generi un file della libreria con un'estensione .so.

LIBRERIA_STATIC_DI_CREAZIONE

Una variante di BUILD_SHARED_LIBRARY utilizzata per creare una libreria statica. La non copia le librerie statiche nel progetto/nei pacchetti, ma possono utilizzarle per creare librerie condivise (vedi LOCAL_STATIC_LIBRARIES e LOCAL_WHOLE_STATIC_LIBRARIES, di seguito). La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_STATIC_LIBRARY)

Una variabile static-library fa sì che il sistema di compilazione generi una libreria con un .a.

LIBRERIA_CONDIVISA_PREBUILT

Punta a uno script di build utilizzato per specificare una libreria condivisa predefinita. Non mi piace in nel caso di BUILD_SHARED_LIBRARY e BUILD_STATIC_LIBRARY, in questo caso il valore LOCAL_SRC_FILES non può essere un file di origine. Deve invece essere un unico percorso una libreria condivisa predefinita, come foo/libfoo.so. La sintassi per l'utilizzo di questo è:

include $(PREBUILT_SHARED_LIBRARY)

Puoi anche fare riferimento a una libreria predefinita in un altro modulo utilizzando Variabile LOCAL_PREBUILTS. Per ulteriori informazioni sull'uso delle creatività predefinite, Utilizza librerie predefinite.

LIBRERIA_STATIC_PREBUILT

Uguale a PREBUILT_SHARED_LIBRARY, ma per una libreria statica predefinita. Per Per saperne di più sull'utilizzo delle librerie predefinite, consulta Utilizzare le librerie predefinite.

Variabili di informazioni target

Il sistema di build analizza Android.mk una volta per ogni ABI specificata dall'elemento APP_ABI , solitamente definita nel file Application.mk. Se APP_ABI è all, il sistema di build analizza Android.mk una volta per ABI e l'NDK Google Cloud. Questa sezione descrive le variabili definite dal sistema di compilazione ogni volta che viene analizza Android.mk.

ARCHIVIO_TARGET

La famiglia di CPU scelta come target dal sistema di compilazione durante l'analisi di questo Android.mk . Questa variabile può essere una delle seguenti: arm, arm64, x86 o x86_64.

PIATTAFORMA_TARGET

Il numero a livello di API Android scelto come target dal sistema di compilazione durante l'analisi. Android.mk. Ad esempio, le immagini di sistema Android 5.1 corrispondono Livello API Android 22: android-22. Per un elenco completo dei nomi delle piattaforme immagini di sistema Android corrispondenti, vedi API native. La nell'esempio seguente viene mostrata la sintassi per l'utilizzo di questa variabile:

ifeq ($(TARGET_PLATFORM),android-22)
    # ... do something ...
endif

TARGET_ARCH_ABI

L'ABI scelta come target dal sistema di compilazione durante l'analisi di questo file Android.mk. La tabella 1 mostra l'impostazione ABI utilizzata per ciascuna CPU e architettura supportate.

Tabella 1. Impostazioni ABI per CPU e architetture diverse.

CPU e architettura	Impostazione
ARMv7	armeabi-v7a
ARMv8 AArch64	arm64-v8a
i686	x86
x86-64	x86_64

L'esempio seguente mostra come verificare ARMv8 AArch64 come target Combinazione di CPU e ABI:

ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
  # ... do something ...
endif

Per ulteriori dettagli sulle ABI dell'architettura e sui problemi di compatibilità associati, Fai riferimento alle ABI Android.

Le nuove ABI target in futuro avranno valori diversi.

TARGET_ABI

Una concatenazione del livello API Android target e dell'ABI. È particolarmente utile quando vuoi eseguire il test con un'immagine di sistema target specifica per un dispositivo reale. Ad esempio, per controllare un dispositivo ARM a 64 bit in esecuzione sul livello API Android 22:

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
  # ... do something ...
endif

Variabili di descrizione del modulo

Le variabili in questa sezione descrivono il modulo al sistema di compilazione. Ciascuna la descrizione del modulo deve seguire questo flusso di base:

1. Inizializza o non definisci le variabili associate al modulo utilizzando il metodo Variabile CLEAR_VARS.
2. Assegna i valori alle variabili utilizzate per descrivere il modulo.
3. Imposta il sistema di compilazione NDK in modo che utilizzi lo script di build appropriato per il modulo. utilizzando la variabile BUILD_XXX.

PERCORSO LOCALE

Questa variabile viene utilizzata per fornire il percorso del file corrente. Devi definirlo all'inizio del tuo file Android.mk. L'esempio seguente mostra come fare quindi:

LOCAL_PATH := $(call my-dir)

Lo script a cui punta CLEAR_VARS non cancella questa variabile. Pertanto, devi definirla una sola volta, anche se il tuo file Android.mk descrive più moduli.

MODULO_LOCALE

Questa variabile memorizza il nome del modulo. Deve essere univoco tra tutti i moduli e non devono contenere spazi. Devi definirlo prima di includere qualsiasi (diverso da quello relativo a CLEAR_VARS). Non è necessario aggiungere lib o l'estensione del file .so o .a. il sistema di compilazione le modifiche in modo automatico. In Android.mk e Application.mk file, fai riferimento al modulo usando il nome non modificato. Ad esempio, riga genera un modulo della libreria condivisa denominato libfoo.so:

LOCAL_MODULE := "foo"

Se vuoi che il modulo generato abbia un nome diverso da lib + il valore di LOCAL_MODULE, puoi utilizzare la variabile LOCAL_MODULE_FILENAME per assegnare per il modulo generato con un nome a tua scelta.

LOCAL_MODULE_FILENAME

Questa variabile facoltativa consente di ignorare i nomi assegnati al sistema di compilazione utilizza per impostazione predefinita per i file che genera. Ad esempio, se il nome del tuo LOCAL_MODULE è foo, puoi forzare il sistema a chiamare il file che genera libnewfoo. L'esempio seguente mostra come eseguire questa operazione:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

Per un modulo della Libreria condivisa, questo esempio genera un file denominato libnewfoo.so.

LOCAL_SRC_FILES

Questa variabile contiene l'elenco dei file di origine che il sistema di compilazione utilizza per generare il modulo. Elenca solo i file effettivamente trasmessi dal sistema di compilazione al compilatore, dato che il sistema di compilazione calcola automaticamente eventuali delle dipendenze. Tieni presente che puoi utilizzare sia valori relativi (per LOCAL_PATH) che assoluti per i file YAML.

Consigliamo di evitare percorsi di file assoluti, per i percorsi relativi, Android.mk portabilità del file.

LOCAL_CPP_EXTENSION

Puoi utilizzare questa variabile facoltativa per indicare un'estensione del file diversa da .cpp per i file sorgente C++. Ad esempio, la riga seguente modifica estensione a .cxx. L'impostazione deve includere il punto.

LOCAL_CPP_EXTENSION := .cxx

Puoi utilizzare questa variabile per specificare più estensioni. Ad esempio:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

Puoi utilizzare questa variabile facoltativa per indicare che il codice si basa su specifiche C++. Abilita i flag corretti del compilatore e del linker durante la build e il processo di sviluppo. Per i file binari predefiniti, questa variabile dichiara anche quali caratteristiche dipende dal file binario e ciò contribuisce a garantire il corretto funzionamento del collegamento finale. Me consigliamo di utilizzare questa variabile anziché attivare -frtti e -fexceptions direttamente nella definizione di LOCAL_CPPFLAGS.

L'uso di questa variabile consente al sistema di compilazione di usare i flag appropriati per in ogni modulo. L'uso di LOCAL_CPPFLAGS fa sì che il compilatore utilizzi tutte le risorse specificate per tutti i moduli, indipendentemente dalle esigenze effettive.

Ad esempio, per indicare che il codice utilizza RTTI (RunTime Type Information), Scrivi:

LOCAL_CPP_FEATURES := rtti

Per indicare che il codice utilizza eccezioni C++, scrivi:

LOCAL_CPP_FEATURES := exceptions

Per questa variabile puoi anche specificare più valori. Ad esempio:

LOCAL_CPP_FEATURES := rtti features

L'ordine in cui descrivi i valori non è importante.

LOCAL_C_INCLUDES

Puoi utilizzare questa variabile facoltativa per specificare un elenco di percorsi relativi Directory NDK root, da aggiungere al percorso di ricerca di inclusione durante la compilazione di tutte (C, C++ e Assembly). Ad esempio:

LOCAL_C_INCLUDES := sources/foo

Oppure:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo

Definisci questa variabile prima di impostare eventuali flag di inclusione corrispondenti tramite LOCAL_CFLAGS o LOCAL_CPPFLAGS.

Il sistema di compilazione utilizza automaticamente anche LOCAL_C_INCLUDES percorsi all'avvio il debug nativo con ndk-gdb.

CFLAG LOCALI

Questa variabile facoltativa imposta i flag del compilatore che il sistema di compilazione deve passare quando creare file sorgente C e C++. Questa possibilità può essere utile a che specifica ulteriori definizioni di macro o opzioni di compilazione. Usa LOCAL_CPPFLAGS per specificare flag solo per C++.

Cerca di non modificare il livello di ottimizzazione/debug nel file Android.mk. Il sistema di compilazione è in grado di gestire automaticamente questa impostazione, utilizzando le informazioni pertinenti nel file Application.mk. In questo modo per generare file di dati utili utilizzati durante il debug.

È possibile specificare percorsi di inclusione aggiuntivi scrivendo:

LOCAL_CFLAGS += -I<path>,

È comunque meglio utilizzare LOCAL_C_INCLUDES a questo scopo, dato che rende possibile l'utilizzo dei percorsi disponibili per il debug nativo con ndk-gdb.

CPPFLAG LOCALI

Set facoltativo di flag del compilatore che verranno passati durante la creazione dell'origine C++ solo file. Verranno visualizzati dopo il LOCAL_CFLAGS nella barra dalla riga di comando. Usa LOCAL_CFLAGS per specificare i flag sia per C che per C++.

LIBRERIE_STATICHE_LOCALI

Questa variabile archivia l'elenco dei moduli delle librerie statiche in cui l'attuale dipende dal modulo.

Se il modulo corrente è una libreria condivisa o un eseguibile, questa variabile forzare il collegamento di queste librerie nel file binario risultante.

Se il modulo corrente è una libreria statica, questa variabile indica semplicemente che gli altri moduli, a seconda di quello attuale, dipenderanno anche dalla configurazione librerie.

LIBRERIE_LOCAL_SHARED_LIBRARI

Questa variabile è l'elenco dei moduli delle librerie condivise in cui questo modulo dipende dal runtime. Queste informazioni sono necessarie al momento del collegamento e per incorporare il le informazioni corrispondenti nel file generato.

LIBRERIE_STATICHE_INTERE_LOCALI

Questa variabile è una variante di LOCAL_STATIC_LIBRARIES ed esprime il fatto che la variabile il linker deve considerare i moduli della biblioteca associati come interi archivi. Per ulteriori informazioni su interi archivi, consulta la documentazione di GNU ld per i Flag --whole-archive.

Questa variabile è utile quando ci sono dipendenze circolari tra diversi librerie statiche. Quando utilizzi questa variabile per creare una libreria condivisa, questa costringe il sistema di compilazione ad aggiungere tutti i file oggetto delle librerie statiche alla binario finale. Lo stesso non è vero, però, quando si generano gli eseguibili.

LIBRE_LOCALI

Questa variabile contiene l'elenco dei flag del linker aggiuntivi da usare negli edifici nella libreria condivisa o eseguibile. Ti consente di usare il prefisso -l per trasmettere il nome di librerie di sistema specifiche. Ad esempio, l'esempio seguente indica il linker per generare un modulo che rimanda a /system/lib/libz.so al caricamento volta:

LOCAL_LDLIBS := -lz

Per l'elenco delle librerie di sistema esposte a cui puoi collegarti in questo NDK consulta la sezione API native.

FLAG_LOCALI

L'elenco di altri flag del linker che il sistema di compilazione può utilizzare durante la creazione libreria condivisa o eseguibile. Ad esempio, per utilizzare il linker ld.bfd su ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Per impostazione predefinita, quando il sistema di compilazione rileva un riferimento non definito durante il tentativo di creare un elemento condiviso, visualizzerà un errore relativo a un simbolo non definito. Questo può aiutarti a individuare i bug nel codice sorgente.

Per disattivare questo controllo, imposta questa variabile su true. Tieni presente che questa impostazione potrebbe causa il caricamento della libreria condivisa in fase di runtime.

LOCAL_ARM_MODE

Per impostazione predefinita, il sistema di compilazione genera file binari di destinazione ARM in modalità thumb. in cui ogni istruzione è larga 16 bit e collegata alle librerie STL del Directory thumb/. La definizione di questa variabile come arm obbliga il sistema di compilazione a generare i file oggetto del modulo in modalità arm a 32 bit. Nell'esempio che segue mostra come fare:

LOCAL_ARM_MODE := arm

Puoi anche indicare al sistema di compilazione di creare origini specifiche solo in arm aggiungendo il suffisso .arm ai nomi file di origine. Ad esempio, l'esempio seguente indica al sistema di compilazione di compilare sempre bar.c in modalità ARM, ma creare foo.c in base al valore di LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

Questa variabile è importante solo se scegli come target l'ABI armeabi-v7a. it consente l'utilizzo dei componenti intrinseci del compilatore ARM Advanced SIMD (NEON) in C e C++ nonché le istruzioni NEON nei file Assembly.

Tieni presente che non tutte le CPU basate su ARMv7 supportano le estensioni del set di istruzioni NEON. Per questo motivo, devi eseguire un rilevamento del runtime per poter usare in sicurezza questo codice in fase di runtime. Per ulteriori informazioni, vedi Assistenza Neon e Funzionalità della CPU.

In alternativa, puoi utilizzare il suffisso .neon per specificare che il sistema di compilazione compilare solo file sorgente specifici con il supporto NEON. Nell'esempio seguente, il sistema di compilazione compila foo.c con il supporto per pollici e neon, bar.c con pollice e zoo.c con supporto per ARM e NEON:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

Se utilizzi entrambi i suffissi, .arm deve precedere .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

Per impostazione predefinita, il sistema di compilazione compila il codice con la protezione da stringhe di formato. Attività quindi forza un errore del compilatore se in una stringa di formato non costante viene utilizzata Funzione di tipo printf. Questa protezione è attiva per impostazione predefinita, ma puoi disattivarla impostando il valore di questa variabile su true. Sconsigliamo di farlo senza un valido motivo.

ESPORTAZIONE_LOCALE_CFLAGS

Questa variabile registra un set di flag del compilatore C/C++ da aggiungere a LOCAL_CFLAGS definizione di qualsiasi altro modulo che utilizzi questo tramite Variabili LOCAL_STATIC_LIBRARIES o LOCAL_SHARED_LIBRARIES.

Ad esempio, considera la seguente coppia di moduli: foo e bar, che dipende da foo:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)


include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

Qui il sistema di compilazione passa i flag -DFOO=1 e -DBAR=2 al compilatore durante la creazione di bar.c. Inoltre, antepone i flag esportati al campo LOCAL_CFLAGS in modo da poterli facilmente sostituire.

Inoltre, la relazione tra i moduli è transitiva: se zoo dipende da bar, che a sua volta dipende da foo; anche zoo eredita tutti i flag esportato da foo.

Infine, il sistema di compilazione non usa flag esportati quando crea in locale (ovvero, la creazione del modulo di cui sta esportando i flag). Pertanto, nell'esempio in alto, non passa -DFOO=1 al compilatore durante la creazione di foo/foo.c. A crea localmente, usa invece LOCAL_CFLAGS.

ESPORTAZIONE_LOCALE_CPPFLAGS

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS, ma solo per i flag C++.

LOCAL_EXPORT_C_INCLUDES

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS, ma per C include i percorsi. it è utile nei casi in cui, ad esempio, bar.c deve includere intestazioni da modulo foo.

ESPORTAZIONE_LOCALIZZATA_LDFLAGS

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS, ma per i flag linker.

ESPORTAZIONE_LOCALIZZATA_LDLIB

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS e indica al sistema di compilazione di passa i nomi di librerie di sistema specifiche al compilatore. Anteponi -l al di ogni libreria specificata.

Tieni presente che il sistema di compilazione aggiunge i flag del linker importati al valore del tuo della variabile LOCAL_LDLIBS del modulo. Ciò è dovuto al funzionamento dei linker Unix.

Questa variabile è in genere utile quando il modulo foo è una libreria statica e ha che dipende da una libreria di sistema. Dopodiché potrai utilizzare LOCAL_EXPORT_LDLIBS per per esportare la dipendenza. Ad esempio:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_LDLIBS := -llog
include $(BUILD_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

In questo esempio, il sistema di compilazione inserisce -llog alla fine del comando linker quando crea libbar.so. Questa operazione comunica al linker che, poiché libbar.so dipende da foo, dipende anche dalla libreria di logging di sistema.

LOCAL_SHORT_commandS

Imposta questa variabile su true quando il modulo ha un numero molto elevato di fonti e/o librerie statiche o condivise dipendenti. Questa operazione costringe il sistema di compilazione a utilizza la sintassi @ per gli archivi contenenti link o file di oggetti intermedi librerie.

Questa funzionalità può essere utile su Windows, dove la riga di comando accetta un di soli 8191 caratteri, che potrebbe essere troppo piccolo per progetti complessi. Inoltre, influisce sulla compilazione dei singoli file sorgente, posizionando quasi tutto il compilatore anche all'interno di file di elenco.

Tieni presente che qualsiasi valore diverso da true tornerà al comportamento predefinito. Tu puoi anche definire APP_SHORT_COMMANDS nel file Application.mk per forzare questo comportamento per tutti i moduli del progetto.

Sconsigliamo di abilitare questa funzionalità per impostazione predefinita, poiché rende la build più lento.

ARCHIVIO_LOCALE_THIN

Imposta questa variabile su true durante la creazione di librerie statiche. In questo modo generare un archivio sottile, ovvero un file di libreria che non contiene file oggetto, ma solo percorsi di file degli oggetti effettivi che normalmente contengono.

Questo è utile per ridurre le dimensioni dell'output della build. Lo svantaggio è che Queste librerie non possono essere spostate in una posizione diversa (tutti i percorsi al loro interno sono relativi).

I valori validi sono true, false o vuoto. Puoi impostare un valore predefinito nel Application.mk tramite la variabile APP_THIN_ARCHIVE.

LOCAL_FILTER_ASM

Definisci questa variabile come un comando shell che il sistema di compilazione utilizzerà per filtrare i file assembly estratti o generati dai file specificati LOCAL_SRC_FILES. La definizione di questa variabile determina quanto segue:

1. Il sistema di compilazione genera un file di assembly temporaneo da qualsiasi origine C o C++ anziché compilarli in un file oggetto.
2. Il sistema di compilazione esegue il comando shell in LOCAL_FILTER_ASM su qualsiasi file di assembly temporaneo e su tutti i file di assembly elencati in LOCAL_SRC_FILES, generando così un altro file di Assembly temporaneo.
3. Il sistema di compilazione compila questi file di assembly filtrati in un file oggetto.

Ad esempio:

LOCAL_SRC_FILES  := foo.c bar.S
LOCAL_FILTER_ASM :=

foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

"1" corrisponde al compilatore "2" al filtro e "3" all'assemblatore. Il filtro deve essere un comando shell autonomo che prende il nome dell'input e il nome del file di output come secondo argomento. Ad esempio:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S

Macro di funzione fornite da NDK

Questa sezione spiega le macro delle funzioni GNU Make messe a disposizione dall'NDK. Utilizza le funzionalità di $(call <function>) per valutarli; restituiscono informazioni testuali.

mia-dir

Questa macro restituisce il percorso dell'ultimo makefile incluso, che in genere è la directory di Android.mk attuale. my-dir è utile per definire LOCAL_PATH all'inizio del file Android.mk. Ad esempio:

LOCAL_PATH := $(call my-dir)

Per via del funzionamento di GNU Make, la macro restituisce il percorso del l'ultimo makefile incluso dal sistema di compilazione durante l'analisi degli script di build. Per per questo motivo, non devi chiamare my-dir dopo aver incluso un altro file.

Considera ad esempio il seguente:

LOCAL_PATH := $(call my-dir)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(call my-dir)

# ... declare another module

Il problema qui è che la seconda chiamata a my-dir definisce LOCAL_PATH come $PATH/foo anziché $PATH, perché è qui che è stata inclusa la più recente a punta.

Puoi evitare questo problema inserendo "include" dopo tutto il resto nel file Android.mk. Ad esempio:

LOCAL_PATH := $(call my-dir)

# ... declare one module

LOCAL_PATH := $(call my-dir)

# ... declare another module

# extra includes at the end of the Android.mk file
include $(LOCAL_PATH)/foo/Android.mk

Se non è possibile strutturare il file in questo modo, salva il valore del parametro prima chiamata my-dir in un'altra variabile. Ad esempio:

MY_LOCAL_PATH := $(call my-dir)

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare another module

tutti-subdir-makefiles

Restituisce l'elenco di file Android.mk situati in tutte le sottodirectory del percorso my-dir corrente.

Puoi utilizzare questa funzione per fornire gerarchie di directory di origine nidificate in modo approfondito il sistema di compilazione. Per impostazione predefinita, NDK cerca solo i file presenti nella directory contenente il file Android.mk.

questo-makefile

Restituisce il percorso del makefile corrente (da cui il sistema di compilazione ha chiamato ).

principale-makefile

Restituisce il percorso del makefile padre nell'albero di inclusione (il percorso del makefile che includeva quello corrente).

fare-file-non-genitore

Restituisce il percorso del makefile principale nell'albero di inclusione (il percorso il makefile che includeva quello corrente).

modulo-importazione

Una funzione che ti consente di trovare e includere il file Android.mk di un modulo tramite il nome del modulo. Ecco un esempio tipico:

$(call import-module,<name>)

In questo esempio, il sistema di compilazione cerca il modulo con tag <name> in l'elenco di directory a cui viene fatto riferimento nell'ambiente NDK_MODULE_PATH riferimenti alle variabili e include automaticamente il relativo file Android.mk.