Auf dieser Seite wird die Syntax der Build-Datei Android.mk
beschrieben, die von
ndk-build
.
Übersicht
Die Datei Android.mk
befindet sich in einem Unterverzeichnis der Datei jni/
Ihres Projekts.
und beschreibt Ihre Quellen und gemeinsam genutzten Bibliotheken im Build-System.
Es ist ein winziges GNU-Makefile-Fragment, das das Build-System einmal parst
mehr. Die Datei Android.mk
ist nützlich, um projektweite Einstellungen zu definieren,
Application.mk
, das Build-System und Ihre Umgebungsvariablen
nicht definiert. Außerdem lassen sich damit projektweite Einstellungen für bestimmte Module überschreiben.
Mit der Syntax von Android.mk
kannst du Quellen in Modulen gruppieren.
Ein Modul ist entweder eine statische Bibliothek, eine gemeinsam genutzte Bibliothek oder eine eigenständige Bibliothek.
ausführbar sein. Sie können in jeder Android.mk
-Datei ein oder mehrere Module definieren.
können Sie dieselbe Quelldatei
in mehreren Modulen verwenden. Nur das Build-System
fügt freigegebene Bibliotheken
in Ihr Anwendungspaket ein. Außerdem werden statische
können gemeinsam genutzte Bibliotheken
generieren.
Neben der Paketerstellung für Bibliotheken verarbeitet das Build-System auch
für Sie. Sie müssen z. B. keine Header-Dateien oder expliziten
zwischen den generierten Dateien in der Datei Android.mk
. Der NDK-Build
diese Beziehungen automatisch für Sie. Daher sollten Sie
sollte im zukünftigen NDK von der neuen Toolchain-/Plattformunterstützung profitieren können.
veröffentlicht, ohne deine Android.mk
-Datei bearbeiten zu müssen.
Die Syntax dieser Datei ist der Syntax der Android.mk
-Dateien sehr ähnlich.
vertrieben werden, die über das vollständige Android Open Source-Projekt vertrieben werden. Während das Build-System
Implementierung, bei der sie anders sind, ist ihre Ähnlichkeit eine beabsichtigte
Designentscheidung, die Anwendungsentwicklern die Wiederverwendung
für externe Bibliotheken.
Grundlegende Informationen
Bevor Sie sich genauer mit der Syntax befassen, sollten Sie sich zunächst
Grundlagen des Inhalts einer Android.mk
-Datei In diesem Abschnitt wird die Methode
Android.mk
im Hello-JNI-Beispiel. Hier wird die Rolle erklärt.
jede Zeile in der Datei abgespielt wird.
Eine Android.mk
-Datei muss mit der Definition der Variable LOCAL_PATH
beginnen:
LOCAL_PATH := $(call my-dir)
Diese Variable gibt den Speicherort der Quelldateien in der Entwicklung an
Baum. Hier gibt die vom Build-System bereitgestellte Makrofunktion my-dir
Pfad des aktuellen Verzeichnisses (Verzeichnis mit der Datei Android.mk
)
-Datei selbst).
In der nächsten Zeile wird die Variable CLEAR_VARS
deklariert, deren Wert das Build-System
.
include $(CLEAR_VARS)
Die Variable CLEAR_VARS
verweist auf ein spezielles GNU-Makefile, mit dem viele
LOCAL_XXX
-Variablen für Sie, wie LOCAL_MODULE
, LOCAL_SRC_FILES
und
LOCAL_STATIC_LIBRARIES
Hinweis: LOCAL_PATH
wird nicht gelöscht. Dieses
Variable muss ihren Wert beibehalten, da das System alle Build-Steuerdateien parst.
in einem einzigen GNU Make-Ausführungskontext, in dem alle Variablen global sind. Du musst
(re-)deklarieren Sie diese Variable, bevor Sie die einzelnen Module beschreiben.
Als Nächstes speichert die Variable LOCAL_MODULE
den Namen des Moduls, das Sie
erstellen. Verwenden Sie diese Variable einmal pro Modul in Ihrer Anwendung.
LOCAL_MODULE := hello-jni
Jeder Modulname muss eindeutig sein und darf keine Leerzeichen enthalten. Das Build-System,
beim Erstellen der endgültigen Datei aus der gemeinsam genutzten Bibliothek, werden automatisch die entsprechenden
Präfix und Suffix zu dem Namen, den Sie LOCAL_MODULE
zuweisen. Beispiel:
Im Beispiel oben wird eine Bibliothek mit dem Namen
libhello-jni.so
In der nächsten Zeile sind die Quelldateien aufgeführt, wobei durch Leerzeichen mehrere Dateien:
LOCAL_SRC_FILES := hello-jni.c
Die Variable LOCAL_SRC_FILES
muss eine Liste von C- und/oder C++-Quelldateien enthalten.
ein Modul zu erstellen.
Die letzte Zeile hilft dem System, alles miteinander zu verknüpfen:
include $(BUILD_SHARED_LIBRARY)
Die Variable BUILD_SHARED_LIBRARY
verweist auf ein Skript in GNU Makefile, das
alle Informationen erfasst, die Sie in LOCAL_XXX
-Variablen definiert haben,
include
zuletzt verwendet. Dieses Skript bestimmt, was erstellt wird und wie es ausgeführt wird.
In den Beispielverzeichnissen befinden sich komplexere Beispiele,
Android.mk
-Dateien, die du dir ansehen kannst. Außerdem enthält Beispiel: native Aktivität
enthält eine ausführliche Erklärung der Android.mk
-Datei dieses Beispiels. Schließlich:
Unter Variablen und Makros finden Sie weitere Informationen zu den Variablen in diesem
.
Variablen und Makros
Das Build-System bietet viele mögliche Variablen zur Verwendung in der Datei Android.mk
.
Viele dieser Variablen haben vorab zugewiesene Werte. Andere weisen Sie zu.
Zusätzlich zu diesen Variablen können Sie auch eigene willkürliche Variablen definieren. Behalten Sie in diesem Fall dass das NDK-Build-System die folgenden Variablennamen reserviert:
- Namen, die mit
LOCAL_
beginnen, z. B.LOCAL_MODULE
. - Namen, die mit
PRIVATE_
,NDK_
oderAPP
beginnen. Das Build-System verwendet diese intern nutzen. - Kleinbuchstaben, z. B.
my-dir
Das Build-System verwendet diese intern, gut.
Wenn Sie Ihre eigenen Convenience-Variablen in einer Android.mk
-Datei definieren müssen,
empfehlen, den Namen MY_
voranzustellen.
NDK-definierte einzuschließende Variablen
In diesem Abschnitt werden die vom Build-System definierten GNU Make-Variablen erläutert.
bevor Sie die Android.mk
-Datei parsen. Unter bestimmten Umständen kann das NDK
Ihre Android.mk
-Datei wird möglicherweise mehrmals mit einer anderen Definition geparst
für einige dieser Variablen.
VARIANZEN_LÖSCHEN
Diese Variable verweist auf ein Build-Skript, das fast alle LOCAL_XXX
undefiniert.
Variablen, die unter „Vom Entwickler definierte Variablen“ aufgeführt sind weiter unten. Verwenden
um dieses Skript einzubinden, bevor ein neues Modul beschrieben wird. Die Syntax für
wie Sie sie verwenden:
include $(CLEAR_VARS)
ERSTELLUNG_AUSFÜHRBAR
Diese Variable verweist auf ein Build-Skript, das alle Informationen
das Modul, das Sie in Ihren LOCAL_XXX
-Variablen bereitgestellt haben, und bestimmt, wie
eine ausführbare Zieldatei aus den aufgeführten Quellen erstellen Beachten Sie, dass die Verwendung dieser
müssen Sie bereits Werte für LOCAL_MODULE
und
LOCAL_SRC_FILES
(weitere Informationen zu diesen Variablen finden Sie unter
Variablen für Modulbeschreibung).
Die Syntax für die Verwendung dieser Variablen lautet:
include $(BUILD_EXECUTABLE)
GEMEINSAM GENUTZTE_BIBLIOTHEK
Diese Variable verweist auf ein Build-Skript, das alle Informationen
das Modul, das Sie in Ihren LOCAL_XXX
-Variablen bereitgestellt haben, und bestimmt, wie
eine gemeinsam genutzte Zielbibliothek aus den aufgeführten Quellen erstellen Beachten Sie, dass die Verwendung dieser
müssen Sie bereits Werte für LOCAL_MODULE
und
LOCAL_SRC_FILES
(weitere Informationen zu diesen Variablen finden Sie unter
Variablen für Modulbeschreibung).
Die Syntax für die Verwendung dieser Variablen lautet:
include $(BUILD_SHARED_LIBRARY)
Eine Variable für die gemeinsam genutzte Bibliothek führt dazu, dass das Build-System eine Bibliotheksdatei generiert.
mit der Erweiterung .so
.
STATISCHE_BIBLIOTHEK_ERSTELLEN
Eine Variante von BUILD_SHARED_LIBRARY
, die zum Erstellen einer statischen Bibliothek verwendet wird. Die
erstellt das Build-System statische Bibliotheken nicht in Ihr Projekt/Ihre Pakete,
können damit gemeinsam genutzte Bibliotheken erstellen (siehe LOCAL_STATIC_LIBRARIES
und
LOCAL_WHOLE_STATIC_LIBRARIES
. Die Syntax für die Verwendung dieser Variablen lautet:
include $(BUILD_STATIC_LIBRARY)
Eine statische-library-Variable bewirkt, dass das Build-System eine Bibliothek mit einem
Erweiterung .a
.
VORTEILE_GEMEINSAM GENUTZTE_BIBLIOTHEK
Verweist auf ein Build-Skript, mit dem eine vordefinierte gemeinsam genutzte Bibliothek angegeben wird. „Mag ich“-Bewertung in
den Fall von BUILD_SHARED_LIBRARY
und BUILD_STATIC_LIBRARY
, hier der Wert von
LOCAL_SRC_FILES
kann keine Quelldatei sein. Stattdessen muss es ein einzelner Pfad zum
vordefinierte gemeinsam genutzte Bibliothek, z. B. foo/libfoo.so
Die Syntax für die Verwendung dieses
Variable lautet:
include $(PREBUILT_SHARED_LIBRARY)
Sie können auch in einem anderen Modul auf eine vordefinierte Bibliothek verweisen, indem Sie die Methode
LOCAL_PREBUILTS
. Weitere Informationen zur Verwendung von vordefinierten
Vordefinierte Bibliotheken verwenden
VORABVERTEILTE_STATISCHE_BIBLIOTHEK
Entspricht PREBUILT_SHARED_LIBRARY
, aber für eine vordefinierte statische Bibliothek. Für
Weitere Informationen zur Verwendung von vordefinierten Bibliotheken finden Sie unter Vordefinierte Bibliotheken verwenden.
Variablen für Zielinformationen
Das Build-System parst Android.mk
einmal pro ABI, das durch APP_ABI
angegeben wird
Variable definiert, die normalerweise in der Datei Application.mk
definiert ist. Wenn APP_ABI
all
ist, parst das Build-System Android.mk
einmal pro ABI und dem NDK.
unterstützt. In diesem Abschnitt werden Variablen beschrieben, die das Build-System jedes Mal definiert, wenn es
parst Android.mk
.
ZIELARCH
Die CPU-Familie, auf die das Build-System ausgerichtet ist, während es diese Android.mk
parst
-Datei. Diese Variable ist entweder arm
, arm64
, x86
oder x86_64
.
ZIELPLATTFORM
Die Nummer des Android-API-Levels, auf die das Build-System beim Parsen ausgerichtet ist
Android.mk
-Datei. Die Systemabbilder von Android 5.1 entsprechen beispielsweise
Android API-Level 22: android-22
. Eine vollständige Liste der Plattformnamen und
entsprechenden Android-System-Images finden Sie unter Native APIs. Die
Das folgende Beispiel zeigt die Syntax für die Verwendung dieser Variablen:
ifeq ($(TARGET_PLATFORM),android-22)
# ... do something ...
endif
ABI_ZIEL_ARCH
Die ABI, auf die das Build-System ausgerichtet ist, während es diese Android.mk
-Datei parst.
Tabelle 1 zeigt die ABI-Einstellung, die für jede unterstützte CPU und Architektur verwendet wird.
Tabelle 1 ABI-Einstellungen für verschiedene CPUs und Architekturen.
CPU und Architektur | Einstellung |
---|---|
ARMv7 | armeabi-v7a |
ARMv8 AArch64 | arm64-v8a |
i686 | x86 |
x86–64 | x86_64 |
Das folgende Beispiel zeigt, wie nach ARMv8 AArch64 als Ziel gesucht wird Kombination aus CPU und ABI:
ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
# ... do something ...
endif
Weitere Informationen zu Architektur-ABIs und zugehörigen Kompatibilitätsproblemen siehe Android-ABIs.
Neue Ziel-ABIs werden in Zukunft andere Werte haben.
ABI-ZIEL
Eine Verkettung von Android-Ziel-API-Level und ABI. Das ist besonders nützlich, wenn Sie einen Test mit einem bestimmten Zielsystem-Image für ein echtes Gerät durchführen möchten. So suchen Sie beispielsweise nach einem 64-Bit-ARM-Gerät mit Android API-Level 22:
ifeq ($(TARGET_ABI),android-22-arm64-v8a)
# ... do something ...
endif
Variablen für Modulbeschreibung
Die Variablen in diesem Abschnitt beschreiben Ihr Modul für das Build-System. Jedes sollte die Modulbeschreibung diesem grundlegenden Ablauf folgen:
- Initialisieren oder definieren Sie die mit dem Modul verknüpften Variablen mithilfe der Methode
CLEAR_VARS
. - Weisen Sie den Variablen, die zur Beschreibung des Moduls verwendet werden, Werte zu.
- Legen Sie fest, dass das NDK-Build-System das entsprechende Build-Skript für das Modul verwendet.
mit der Variablen
BUILD_XXX
.
LOKALER_PFAD
Diese Variable wird verwendet, um den Pfad der aktuellen Datei anzugeben. Sie müssen ihn definieren.
am Anfang Ihrer Android.mk
-Datei. Das folgende Beispiel zeigt, wie Sie
Also:
LOCAL_PATH := $(call my-dir)
Das Skript, auf das CLEAR_VARS
verweist, löscht diese Variable nicht. Dementsprechend wird
brauchen Sie sie nur einmal zu definieren, auch wenn Ihre Android.mk
-Datei
beschreibt mehrere Module.
LOKALES_MODUL
Diese Variable speichert den Namen Ihres Moduls. Er muss unter allen Modulen eindeutig sein
Namen und darf keine Leerzeichen enthalten. Sie müssen ihn definieren, bevor
Skripts (außer dem für CLEAR_VARS
) Sie müssen weder das Element lib
oder die Dateiendung .so
oder .a
. macht das Build-System diese
automatisch ändern. Während des gesamten Android.mk
und Application.mk
-Dateien verweisen auf das Modul mit seinem unveränderten Namen. Beispiel:
führt zur Generierung eines Moduls der gemeinsam genutzten Bibliothek namens libfoo.so
:
LOCAL_MODULE := "foo"
Wenn das generierte Modul einen anderen Namen als lib
+ den Wert von
LOCAL_MODULE
haben, können Sie die Variable LOCAL_MODULE_FILENAME
verwenden,
stattdessen einen Namen Ihrer Wahl generiert.
LOCAL_MODULE_FILENAME
Mit dieser optionalen Variablen können Sie die Namen überschreiben, die vom Build-System
standardmäßig für Dateien, die es erstellt. Wenn beispielsweise der Name Ihres
LOCAL_MODULE
gleich foo
ist, können Sie erzwingen, dass das System die generierte Datei aufruft.
libnewfoo
Das folgende Beispiel zeigt, wie Sie dies erreichen:
LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo
Für ein Modul der gemeinsam genutzten Bibliothek würde in diesem Beispiel eine Datei namens
libnewfoo.so
LOKALE_SRC-DATEIEN
Diese Variable enthält die Liste der Quelldateien, die das Build-System verwendet, um
um das Modul zu generieren. Nur die Dateien auflisten, die vom Build-System tatsächlich übergeben werden
an den Compiler übergeben, da das Build-System automatisch alle verknüpften
Abhängigkeiten. Beachten Sie, dass Sie sowohl relative (zu LOCAL_PATH
) als auch absolute
Dateipfaden.
Wir empfehlen, absolute Dateipfade zu vermeiden. relative Pfade machen Android.mk
Datei leichter portierbar sein.
LOKALE_CPP_ERWEITERUNG
Sie können diese optionale Variable verwenden, um eine andere Dateiendung als
.cpp
für Ihre C++-Quelldateien. Mit der folgenden Zeile wird beispielsweise
Erweiterung auf .cxx
. (Die Einstellung muss einen Punkt enthalten.)
LOCAL_CPP_EXTENSION := .cxx
Sie können diese Variable verwenden, um mehrere Erweiterungen anzugeben. Beispiel:
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
LOKALE_CPP-FUNKTIONEN
Sie können diese optionale Variable verwenden, um anzugeben, dass Ihr Code auf bestimmten
C++ Funktionen. Während des Builds werden die richtigen Compiler- und Verknüpfungs-Flags aktiviert.
. Bei vordefinierten Binärdateien deklariert diese Variable auch, welche Funktionen
hängt davon ab, ob die endgültige Verknüpfung korrekt funktioniert. Mi.
empfehlen, diese Variable zu verwenden, anstatt -frtti
und
-fexceptions
direkt in Ihrer LOCAL_CPPFLAGS
-Definition.
Mit dieser Variablen kann das Build-System die entsprechenden Flags für
zu den einzelnen Modulen. Bei Verwendung von LOCAL_CPPFLAGS
verwendet der Compiler alle angegebenen
für alle Module unabhängig vom tatsächlichen Bedarf.
Um beispielsweise anzuzeigen, dass Ihr Code RTTI (RunTime Type Information) verwendet, Schreiben:
LOCAL_CPP_FEATURES := rtti
Um anzugeben, dass Ihr Code C++-Ausnahmen verwendet, schreiben Sie:
LOCAL_CPP_FEATURES := exceptions
Sie können auch mehrere Werte für diese Variable angeben. Beispiel:
LOCAL_CPP_FEATURES := rtti features
Die Reihenfolge, in der Sie die Werte beschreiben, spielt keine Rolle.
LOCAL_C_INCLUDES
Sie können diese optionale Variable verwenden, um eine Liste von Pfaden relativ zum
NDK-Verzeichnis root
, das zum Einschließen-Suchpfad bei der Kompilierung aller
Quellen (C, C++ und Assembly). Beispiel:
LOCAL_C_INCLUDES := sources/foo
Oder sogar:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
Definieren Sie diese Variable, bevor Sie entsprechende Einschluss-Flags über
LOCAL_CFLAGS
oder LOCAL_CPPFLAGS
.
Das Build-System verwendet beim Start auch automatisch LOCAL_C_INCLUDES
-Pfade.
native Debugging-Tools mit ndk-gdb.
LOKALE_UNTERLAGEN
Diese optionale Variable legt Compiler-Flags fest, die vom Build-System übergeben werden, wenn
Erstellen von C-und C++-Quelldateien Die Möglichkeit, dies zu tun, ist nützlich für
zusätzliche Makrodefinitionen oder Kompilierungsoptionen angeben. LOCAL_CPPFLAGS
verwenden
zur Angabe von Flags nur für C++.
Ändern Sie die Optimierungs-/Debug-Ebene in der Datei Android.mk
nicht.
Das Build-System übernimmt diese Einstellung automatisch für Sie, indem es die
relevante Informationen in der Datei Application.mk
. Auf diese Weise können die
um nützliche Datendateien für die Fehlerbehebung zu generieren.
Es ist möglich, zusätzliche Einschlusspfade anzugeben, indem Sie Folgendes schreiben:
LOCAL_CFLAGS += -I<path>,
Es ist jedoch besser, LOCAL_C_INCLUDES
für diesen Zweck zu verwenden, da
Dadurch ist es auch möglich, die für das native Debugging verfügbaren Pfade mit
ndk-gdb.
LOKALE_CPPFLAGS
Ein optionaler Satz von Compiler-Flags, die beim Erstellen der C++-Quelle übergeben werden
nur Dateien. Sie werden nach LOCAL_CFLAGS
in der Compiler-
Befehlszeile. Verwenden Sie LOCAL_CFLAGS
, um Flags sowohl für C als auch für C++ anzugeben.
LOKALE_STATISCHE_BIBLIOTHEKEN
Diese Variable speichert die Liste der statischen Bibliotheksmodule, in denen die aktuelle hängt davon ab.
Wenn das aktuelle Modul eine gemeinsam genutzte Bibliothek oder eine ausführbare Datei ist, wird diese Variable die Verknüpfung dieser Bibliotheken mit der resultierenden Binärdatei erzwingen.
Wenn das aktuelle Modul eine statische Bibliothek ist, gibt diese Variable einfach an, Die anderen Module hängen auch vom aktuellen Modul ab. Bibliotheken.
LOKALE_GEMEINSAM GENUTZTE_BIBLIOTHEKEN
Diese Variable ist die Liste der Module der gemeinsam genutzten Bibliotheken, auf denen dieses Modul basiert. hängt von der Laufzeit ab. Diese Informationen werden zum Zeitpunkt der Verknüpfung und zum Einbetten der die entsprechenden Informationen in der generierten Datei enthalten.
LOKALE_STATISCHE_BIBLIOTHEKEN
Diese Variable ist eine Variante von LOCAL_STATIC_LIBRARIES
und drückt aus, dass die
Linker sollte die zugehörigen Bibliotheksmodule wie ganze Archive behandeln. Für
Weitere Informationen zu ganzen Archiven finden Sie in der GNU ld-Dokumentation für die
--whole-archive
-Flag.
Diese Variable ist nützlich, wenn zwischen mehreren statische Bibliotheken. Wenn Sie diese Variable zum Erstellen einer gemeinsam genutzten Bibliothek verwenden, das Build-System dazu zwingen, alle Objektdateien aus Ihren statischen Bibliotheken zum endgültigen Binärcode. Dies gilt jedoch nicht für die Generierung ausführbarer Dateien.
LOKALE_LDLIBS
Diese Variable enthält die Liste zusätzlicher Verknüpfungs-Flags zum Erstellen von
eine gemeinsam genutzte Bibliothek
oder eine ausführbare Datei zu erstellen. Sie können das Präfix -l
verwenden, um
Namen bestimmter Systembibliotheken. Im folgenden Beispiel sehen Sie,
Verknüpfung zum Generieren eines Moduls, das beim Laden auf /system/lib/libz.so
verweist
Zeit:
LOCAL_LDLIBS := -lz
Eine Liste der veröffentlichten Systembibliotheken, zu denen Sie in diesem NDK eine Verknüpfung herstellen können finden Sie unter Native APIs.
LOKALE_LDFLAGS
Die Liste anderer Verknüpfungs-Flags, die das Build-System beim Erstellen Ihres
eine gemeinsam genutzte Bibliothek
oder eine ausführbare Datei zur Verfügung. Wenn Sie beispielsweise die ld.bfd
-Verknüpfung auf einem
ARM/X86:
LOCAL_LDFLAGS += -fuse-ld=bfd
LOCAL_ALLOW_UNDEFINED_SYMBOLS
Wenn das Build-System auf einen nicht definierten Verweis stößt, wird standardmäßig wird der Fehler undefined symbol ausgegeben. Dieses kann dir dabei helfen, Programmfehler im Quellcode zu finden.
Um diese Prüfung zu deaktivieren, legen Sie diese Variable auf true
fest. Beachten Sie, dass diese Einstellung
dass die gemeinsam genutzte Bibliothek zur Laufzeit geladen wird.
LOCAL_ARM_MODE
Standardmäßig generiert das Build-System ARM-Zielbinärdateien im thumb-Modus.
wobei jeder Befehl 16 Bit breit ist und mit den STL-Bibliotheken im
thumb/
. Wenn Sie diese Variable als arm
definieren, wird das Build-System gezwungen,
Generieren der Objektdateien des Moduls im 32-Bit-Modus arm
. Im folgenden Beispiel
zeigt, wie das geht:
LOCAL_ARM_MODE := arm
Sie können das Build-System auch anweisen, nur bestimmte Quellen in arm
zu erstellen
Modus, indem Sie das Suffix .arm
an die Namen der Quelldateien anhängen. Beispiel: Der Parameter
Im folgenden Beispiel wird das Build-System angewiesen, bar.c
immer im ARM-Modus zu kompilieren.
sondern um foo.c
entsprechend dem Wert von LOCAL_ARM_MODE
zu erstellen.
LOCAL_SRC_FILES := foo.c bar.c.arm
LOKALER_ARM-NEON
Diese Variable ist nur wichtig, wenn das Targeting auf das ABI „armeabi-v7a
“ erfolgt. Es
ermöglicht die Verwendung von NEON-Compiler-Intrinsiken (ARM Advanced SIMD) in Ihrem C- und C++-
Quellen sowie NEON-Anweisungen in Assembly-Dateien.
Beachten Sie, dass nicht alle ARMv7-basierten CPUs die NEON-Anweisungssatzerweiterungen unterstützen. Aus diesem Grund müssen Sie eine Laufzeiterkennung durchführen, um die um diesen Code zur Laufzeit zu übertragen. Weitere Informationen finden Sie unter Neon-Support und CPU-Features:
Alternativ können Sie mit dem Suffix .neon
angeben, dass das Build-System
bestimmte Quelldateien mit NEON-Unterstützung kompilieren. Im folgenden Beispiel
das Build-System kompiliert foo.c
mit Daumen- und Neon-Unterstützung, bar.c
mit
Daumen hoch und zoo.c
mit Unterstützung für ARM und NEON:
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
Wenn Sie beide Suffixe verwenden, muss .arm
vor .neon
stehen.
LOCAL_DISABLE_FORMAT_STRING_CHECKS
Standardmäßig kompiliert das Build-System Code mit Formatstringschutz. Tun
Erzwingt einen Compilerfehler, wenn ein nicht konstanter Formatstring in einem
printf
-Stil verwenden. Dieser Schutz ist standardmäßig aktiviert, Sie können ihn aber deaktivieren
indem Sie den Wert dieser Variablen auf true
setzen. Wir raten jedoch davon ab,
ohne triftigen Grund.
LOCAL_EXPORT_CFLAGS
Diese Variable zeichnet eine Reihe von C/C++-Compiler-Flags auf, die dem LOCAL_CFLAGS
hinzugefügt werden
eines anderen Moduls, das dieses über die
LOCAL_STATIC_LIBRARIES
oder LOCAL_SHARED_LIBRARIES
.
Betrachten Sie beispielsweise das folgende Modulpaar: foo
und bar
.
ist abhängig von 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)
Hier übergibt das Build-System die Flags -DFOO=1
und -DBAR=2
an den Compiler.
beim Erstellen von bar.c
. Außerdem werden dem Code Ihres Moduls
Exportierte Flags vorangestellt.
LOCAL_CFLAGS
, damit Sie sie einfach überschreiben können.
Darüber hinaus ist die Beziehung zwischen den Modulen transitiv: Wenn zoo
von folgendem Wert abhängt,
bar
, die wiederum von foo
abhängig ist, übernimmt zoo
auch alle Flags
aus foo
exportiert.
Schließlich verwendet das Build-System keine exportierten Flags, wenn es lokal erstellt wird.
(d.h. Erstellen des Moduls, dessen Flags exportiert werden). Daher ist in dem Beispiel
oben angegeben wird, wird -DFOO=1
beim Erstellen von foo/foo.c
nicht an den Compiler übergeben. Bis
lokal erstellen, verwenden Sie stattdessen LOCAL_CFLAGS
.
LOCAL_EXPORT_CPPFLAGS
Diese Variable ist mit LOCAL_EXPORT_CFLAGS
identisch, gilt jedoch nur für C++-Flags.
LOCAL_EXPORT_C_INCLUDES
Diese Variable ist die gleiche wie LOCAL_EXPORT_CFLAGS
, aber für C schließen Sie Pfade ein. Es
ist nützlich, wenn bar.c
beispielsweise Header aus
Modul foo
.
LOCAL_EXPORT_LDFLAGS
Diese Variable ist mit LOCAL_EXPORT_CFLAGS
identisch, gilt jedoch für Verknüpfungs-Flags.
LOCAL_EXPORT_LDLIBS
Diese Variable ist mit LOCAL_EXPORT_CFLAGS
identisch und weist das Build-System an,
Namen bestimmter Systembibliotheken an den Compiler übergeben. -l
dem Abschnitt
Namen jeder von Ihnen angegebenen Bibliothek.
Das Build-System hängt importierte Verknüpfungs-Flags an den Wert Ihres
der Variable LOCAL_LDLIBS
des Moduls. Dies liegt an der Funktionsweise der Unix-Verknüpfung.
Diese Variable ist in der Regel nützlich, wenn das Modul foo
eine statische Bibliothek ist und
der von einer Systembibliothek abhängt. Anschließend können Sie LOCAL_EXPORT_LDLIBS
verwenden, um
um die Abhängigkeit zu exportieren. Beispiel:
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 diesem Beispiel setzt das Build-System -llog
an das Ende des Verknüpfungsbefehls.
wenn libbar.so
erstellt wird. Dadurch wird der Verknüpfung mitgeteilt, dass libbar.so
hängt von foo
ab, aber auch von der System-Logging-Bibliothek.
LOCAL_SHORT_BEFEHLE
Setzen Sie diese Variable auf true
, wenn Ihr Modul eine sehr hohe Anzahl von Quellen hat.
und/oder abhängigen statischen
oder gemeinsam genutzten Bibliotheken. Dadurch wird das Build-System gezwungen,
Verwenden Sie die Syntax @
für Archive, die Zwischenobjektdateien oder Verknüpfungen enthalten
Bibliotheken.
Diese Funktion kann unter Windows nützlich sein, wo die Befehlszeile ein Maximum an von nur 8.191 Zeichen, was für komplexe Projekte zu klein sein kann. Außerdem wirkt sich auf die Kompilierung einzelner Quelldateien aus, sodass fast alle Compiler auch in Listendateien.
Beachten Sie, dass alle Werte außer true
auf das Standardverhalten zurückgesetzt werden. Ich
können Sie auch APP_SHORT_COMMANDS
in Ihrer Application.mk
-Datei definieren, um
in Ihrem Projekt für alle Module.
Wir raten davon ab, diese Funktion standardmäßig zu aktivieren, da dadurch der Build langsamer machen.
LOKALE_THIN_ARCHIV
Legen Sie diese Variable beim Erstellen statischer Bibliotheken auf true
fest. Dadurch wird
ein Thin-Archiv generieren, eine Bibliotheksdatei, die keine Objektdateien enthält,
sondern nur Dateipfade zu den Objekten, die normalerweise
enthalten.
Dies ist nützlich, um die Größe der Build-Ausgabe zu reduzieren. Der Nachteil ist, dass Solche Bibliotheken können nicht an einen anderen Speicherort verschoben werden (alle darin enthaltenen Pfade). relativ sind).
Gültige Werte sind true
, false
oder leer. In Ihrem
Application.mk
-Datei über die Variable APP_THIN_ARCHIVE
.
LOKALER_FILTER_ASM
Definieren Sie diese Variable als Shell-Befehl, den das Build-System zum Filtern verwendet
die Assembly-Dateien, die aus den Dateien extrahiert oder generiert wurden, die Sie für
LOCAL_SRC_FILES
Wenn Sie diese Variable definieren, geschieht Folgendes:
- Das Build-System generiert eine temporäre Assembly-Datei aus einer beliebigen C- oder C++-Quelle. anstatt sie in einer Objektdatei zu kompilieren.
- Das Build-System führt den Shell-Befehl in
LOCAL_FILTER_ASM
auf einem beliebigen temporäre Assembly-Datei und in jeder Assembly-Datei, die inLOCAL_SRC_FILES
aufgeführt ist, und generiert so eine weitere temporäre Assembly-Datei. - Das Build-System kompiliert diese gefilterten Assembly-Dateien in eine Objektdatei.
Beispiel:
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“ entspricht dem Compiler, „2“ mit dem Filter und „3“ mit dem Assembler. Der Filter muss ein eigenständiger Shell-Befehl sein, der den Namen der Eingabe verwendet -Datei als erstes Argument und den Namen der Ausgabedatei als zweites Argument. Beispiel:
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
Von NDK bereitgestellte Funktionsmakros
In diesem Abschnitt werden die Makros der GNU Make-Funktion erläutert, die vom NDK bereitgestellt werden. Verwenden Sie
$(call <function>)
, um sie zu bewerten; geben sie Textinformationen zurück.
my-dir
Dieses Makro gibt den Pfad des letzten eingeschlossenen Makefile zurück, das normalerweise
Das aktuelle Verzeichnis von Android.mk
. my-dir
eignet sich zum Definieren
LOCAL_PATH
am Anfang Ihrer Android.mk
-Datei. Beispiel:
LOCAL_PATH := $(call my-dir)
Aufgrund der Funktionsweise von GNU Make gibt dieses Makro
letztes Makefile, das das Build-System beim Parsen der Build-Skripts verwendet hat. Für
Aus diesem Grund sollten Sie my-dir
nicht aufrufen, nachdem Sie eine weitere Datei eingefügt haben.
Hier ein Beispiel:
LOCAL_PATH := $(call my-dir)
# ... declare one module
include $(LOCAL_PATH)/foo/`Android.mk`
LOCAL_PATH := $(call my-dir)
# ... declare another module
Das Problem ist, dass der zweite Aufruf von my-dir
LOCAL_PATH
als
$PATH/foo
anstelle von $PATH
, da dort die neueste Einbeziehung
spitz.
Sie können dieses Problem vermeiden, indem Sie nach allem anderen "Includes" (Einschließen) einfügen.
in der Datei Android.mk
. Beispiel:
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
Wenn es nicht möglich ist, die Datei auf diese Weise zu strukturieren, speichern Sie den Wert des
ersten my-dir
-Aufruf in eine andere Variable ein. Beispiel:
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
alle-unterverzeichnis-makefiles
Gibt die Liste der Android.mk
-Dateien zurück, die sich in allen Unterverzeichnissen der
Aktueller my-dir
-Pfad.
Mit dieser Funktion können Sie Hierarchien
von tief verschachtelten Quellverzeichnissen für
des Build-Systems. Standardmäßig sucht das NDK nur nach Dateien im Verzeichnis
mit der Datei Android.mk
.
dieses Makefile
Gibt den Pfad des aktuellen Makefile zurück, aus dem das Build-System den .
Parent-Makefile
Gibt den Pfad des übergeordneten Makefile in der Einschlussstruktur zurück (den Pfad des Makefile, in dem das aktuelle Makefile enthalten ist).
Grand-Parent-Makefile
Gibt den Pfad des übergeordneten Makefile im Einschlussbaum zurück (den Pfad von das Makefile, das das aktuelle enthält).
Importmodul
Eine Funktion, mit der Sie die Datei Android.mk
eines Moduls suchen und einschließen können, indem Sie
den Namen des Moduls. Hier ein typisches Beispiel:
$(call import-module,<name>)
In diesem Beispiel sucht das Build-System nach dem Modul <name>
in
die Liste der Verzeichnisse, auf die Ihre NDK_MODULE_PATH
-Umgebung verweist
Variable verweist und die Android.mk
-Datei automatisch für Sie mitnimmt.