Na tej stronie opisano składnię pliku kompilacji Android.mk
używanego przez
ndk-build
Omówienie
Plik Android.mk
znajduje się w podkatalogu jni/
projektu
oraz opisuje Twoje źródła i biblioteki udostępnione w systemie kompilacji.
Jest to naprawdę mały fragment pliku Makefile programu GNU, który system kompilacji analizuje raz lub
i innych. Plik Android.mk
przydaje się do definiowania ustawień projektu, które
Application.mk
, system kompilacji i zmienne środowiskowe nie będą dostępne.
nie zdefiniowano. Może też zastępować ustawienia dotyczące całego projektu dla konkretnych modułów.
Składnia elementu Android.mk
umożliwia grupowanie źródeł w moduły.
Moduł może być biblioteką statyczną, biblioteką współdzieloną lub samodzielną
. W każdym pliku Android.mk
możesz zdefiniować co najmniej 1 moduł.
możesz używać tego samego pliku źródłowego w kilku modułach. Tylko system kompilacji
umieszcza biblioteki udostępnione w pakiecie aplikacji. Poza tym statyczna
biblioteki udostępnione.
Oprócz bibliotek pakietów system kompilacji obsługuje
dla Ciebie. Na przykład nie musisz wymieniać plików nagłówka ani
zależności między wygenerowanymi plikami w pliku Android.mk
. Kompilacja NDK
automatycznie oblicza te relacje. W rezultacie
powinni mieć możliwość skorzystania z nowego łańcucha narzędzi/obsługi platformy w przyszłości w NDK
wersji bez dotykania pliku Android.mk
.
Składnia tego pliku jest bardzo zbliżona do tej w plikach Android.mk
.
rozpowszechniane w ramach całego projektu Android Open Source. System kompilacji
ich zastosowanie wygląda inaczej, ich podobieństwo jest celowe.
decyzji projektowej ma na celu ułatwienie
programistom aplikacji
kod źródłowy bibliotek zewnętrznych.
Podstawy
Zanim szczegółowo zapoznasz się ze składnią, najpierw poznaj
podstawowe informacje o zawartości pliku Android.mk
. W tej sekcji użyto
Android.mk
we fragmencie Hello-JNI, wyjaśniającym rolę
w każdym wierszu pliku.
Plik Android.mk
musi zaczynać się od zdefiniowania zmiennej LOCAL_PATH
:
LOCAL_PATH := $(call my-dir)
Ta zmienna wskazuje lokalizację plików źródłowych w wersji deweloperskiej
drzewo. W tym przypadku funkcja makro my-dir
udostępniona przez system kompilacji zwraca
ścieżkę bieżącego katalogu (czyli katalogu zawierającego Android.mk
pliku).
W następnym wierszu deklaruje się zmienną CLEAR_VARS
, której wartość system kompilacji
co zapewnia.
include $(CLEAR_VARS)
Zmienna CLEAR_VARS
wskazuje specjalny plik GNU Makefile, który usuwa wiele
LOCAL_XXX
, np. LOCAL_MODULE
, LOCAL_SRC_FILES
,
LOCAL_STATIC_LIBRARIES
. Pamiętaj, że nie zostanie usunięte pole LOCAL_PATH
. Ten
zmienna musi zachowywać swoją wartość, ponieważ system analizuje wszystkie pliki sterujące kompilacji
w jednym kontekście wykonawczym GNU Make, w którym wszystkie zmienne mają charakter globalny. Musisz
(ponownie) zadeklaruj tę zmienną przed opisaniem każdego modułu.
Następnie zmienna LOCAL_MODULE
przechowuje nazwę modułu, który chcesz
tworzyć. Użyj tej zmiennej raz w każdym module w swojej aplikacji.
LOCAL_MODULE := hello-jni
Nazwa każdego modułu musi być unikalna i nie może zawierać spacji. System kompilacji
podczas generowania ostatecznego pliku biblioteki współdzielonej automatycznie dodaje odpowiednie
prefiks i przyrostek nazwy przypisanej użytkownikowi LOCAL_MODULE
. Przykład:
Powyższy przykład generuje bibliotekę o nazwie
libhello-jni.so
W następnym wierszu wymienione są pliki źródłowe, przy czym spacje oddzielają wiele pliki:
LOCAL_SRC_FILES := hello-jni.c
Zmienna LOCAL_SRC_FILES
musi zawierać listę plików źródłowych w języku C lub C++
w moduł.
Ostatni wiersz pomaga systemowi powiązać ze sobą wszystkie elementy:
include $(BUILD_SHARED_LIBRARY)
Zmienna BUILD_SHARED_LIBRARY
wskazuje skrypt GNU Makefile, który
zbiera wszystkie informacje określone w zmiennych LOCAL_XXX
od
ostatnich include
. Skrypt określa, co i w jaki sposób utworzyć.
W katalogach przykładów można znaleźć bardziej złożone przykłady z skomentowanymi
Android.mk
plików, które możesz wyświetlić. Dodatkowo Przykład: aktywność natywna
zawiera szczegółowe objaśnienie pliku Android.mk
tego przykładu. I na koniec,
Strona Zmienne i makra zawiera dodatkowe informacje o zmiennych z tego
.
Zmienne i makra
System kompilacji udostępnia wiele możliwych zmiennych do użycia w pliku Android.mk
.
Wiele z tych zmiennych ma wstępnie przypisane wartości. a pozostałe – samodzielnie.
Oprócz tych zmiennych możesz także definiować własne dowolne. W takim przypadku zachowaj pamiętaj, że system kompilacji NDK rezerwuje te nazwy zmiennych:
- Nazwy zaczynające się od
LOCAL_
, na przykładLOCAL_MODULE
. - Nazwy zaczynające się od
PRIVATE_
,NDK_
lubAPP
. System kompilacji używa wewnętrznie. - Nazwy pisane małymi literami, np.
my-dir
. System kompilacji używa ich wewnętrznie, cóż.
Jeśli trzeba zdefiniować własne zmienne w pliku Android.mk
,
zalecamy dodanie MY_
do ich nazw.
Zmienne uwzględniania zdefiniowane przez NDK
W tej sekcji omawiamy zmienne GNU Make, które są definiowane przez system kompilacji
przed analizowaniem pliku Android.mk
. W pewnych okolicznościach NDK
może wielokrotnie przeanalizować plik Android.mk
, używając innej definicji
dla niektórych z tych zmiennych.
WYCZYŚĆ_ODMIANY
Ta zmienna wskazuje skrypt kompilacji, który nie definiuje prawie wszystkich LOCAL_XXX
zmiennych wymienionych na liście „Zmienne zdefiniowane przez programistę” sekcji poniżej. Użyj tej
, aby uwzględnić ten skrypt przed opisaniem nowego modułu. Składnia instrukcji
korzystanie z niej:
include $(CLEAR_VARS)
BUILD_EXECUTABLE
Ta zmienna wskazuje skrypt kompilacji, który zbiera wszystkie informacje na temat
modułem podanym w zmiennych LOCAL_XXX
oraz określa sposób
utwórz docelowy plik wykonywalny na podstawie podanych źródeł. Pamiętaj, że użycie tego
skrypt wymaga, aby były już przypisane wartości do LOCAL_MODULE
oraz
LOCAL_SRC_FILES
przynajmniej (więcej informacji na temat tych zmiennych można znaleźć tutaj:
zmiennych opisu modułu).
Składnia używana do użycia tej zmiennej:
include $(BUILD_EXECUTABLE)
KOMPILD_WSPÓŁDZIELONA_BIBLIOTEKA
Ta zmienna wskazuje skrypt kompilacji, który zbiera wszystkie informacje na temat
modułem podanym w zmiennych LOCAL_XXX
oraz określa sposób
utworzyć docelowe zasoby wspólne na podstawie podanych źródeł. Pamiętaj, że użycie tego
skrypt wymaga, aby były już przypisane wartości do LOCAL_MODULE
oraz
LOCAL_SRC_FILES
przynajmniej (więcej informacji na temat tych zmiennych można znaleźć tutaj:
zmiennych opisu modułu).
Składnia używana do użycia tej zmiennej:
include $(BUILD_SHARED_LIBRARY)
Zmienna biblioteki współdzielonej powoduje, że system kompilacji generuje plik biblioteki.
z rozszerzeniem .so
.
BUILD_STATIC_BIBLIOTEKA
Wariant języka BUILD_SHARED_LIBRARY
używany do tworzenia biblioteki statycznej.
system kompilacji nie kopiuje bibliotek statycznych do projektu/pakietów,
mogą za ich pomocą tworzyć biblioteki udostępnione (zobacz LOCAL_STATIC_LIBRARIES
i
LOCAL_WHOLE_STATIC_LIBRARIES
poniżej). Składnia używana do użycia tej zmiennej:
include $(BUILD_STATIC_LIBRARY)
Zmienna biblioteki statycznej powoduje, że system kompilacji generuje bibliotekę z parametrem
.a
.
BIBLIOTEKA_WSTĘPNA_WSPÓLNA
Wskazuje skrypt kompilacji używany do określenia gotowej biblioteki współdzielonej. Usuń polubienie w
w przypadku BUILD_SHARED_LIBRARY
i BUILD_STATIC_LIBRARY
, tu wartość
LOCAL_SRC_FILES
nie może być plikiem źródłowym. Musi to być jedna ścieżka do
gotowa biblioteka współdzielona, taka jak foo/libfoo.so
. Składnia używana w przypadku tego argumentu
to:
include $(PREBUILT_SHARED_LIBRARY)
Możesz też odwołać się do gotowej biblioteki w innym module, używając
Zmienna LOCAL_PREBUILTS
. Więcej informacji o używaniu gotowych kompilacji znajdziesz w materiałach na temat
Użyj gotowych bibliotek.
PREBUILT_STATIC_BIBLIOTEKA
To samo co PREBUILT_SHARED_LIBRARY
, ale w przypadku gotowej biblioteki statycznej. Dla:
Więcej informacji o używaniu gotowych bibliotek znajdziesz w artykule Korzystanie z gotowych bibliotek.
Docelowe zmienne informacyjne
System kompilacji analizuje Android.mk
raz na interfejs ABI określony przez APP_ABI
, która jest zwykle zdefiniowana w pliku Application.mk
. Jeśli APP_ABI
wynosi all
, system kompilacji analizuje element Android.mk
raz dla każdego interfejsu ABI i NDK
obsługuje. W tej sekcji opisano zmienne definiowane przez system kompilacji za każdym razem,
analizuje element Android.mk
.
ARCH DOCELOWY
Rodzina procesorów, na którą kierowany jest system kompilacji podczas analizowania tego zasobu (Android.mk
)
. Zmienna będzie jedną z tych zmiennych: arm
, arm64
, x86
lub x86_64
.
TARGET_PLATFORMA
Numer poziomu interfejsu API Androida, na który kierowany jest system kompilacji podczas analizowania tego
Android.mk
. Na przykład obrazy systemu Android 5.1 odpowiadają
Interfejs API Androida poziomu 22: android-22
. Pełną listę nazw platform
odpowiednich obrazów systemu Android znajdziesz w artykule Natywne interfejsy API.
przykład poniżej pokazuje składnię użycia tej zmiennej:
ifeq ($(TARGET_PLATFORM),android-22)
# ... do something ...
endif
TARGET_ARCH_ABI
Interfejs ABI, na który kierowany jest system kompilacji podczas analizowania tego pliku Android.mk
.
Tabela 1 przedstawia ustawienie interfejsu ABI używane w przypadku każdego obsługiwanego procesora i architektury.
Tabela 1. Ustawienia ABI dla różnych procesorów i architektur.
Procesor i architektura | Ustawienie |
---|---|
ARM wersja 7 | armeabi-v7a |
ARMv8 AArch64 | arm64-v8a |
i686 | x86 |
x86–64 | x86_64 |
Przykład poniżej pokazuje, jak sprawdzić, czy w środowisku docelowym ARMv8 AArch64 Kombinacja procesora i interfejsu ABI:
ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
# ... do something ...
endif
Więcej informacji o interfejsach ABI architektury i powiązanych problemach ze zgodnością znajdziesz zapoznaj się z interfejsami ABI Androida.
Nowe docelowe interfejsy ABI w przyszłości będą miały inne wartości.
TARGET_ABI
Połączenie docelowego poziomu interfejsu API Androida i interfejsu ABI. Szczególnie przydatne są gdy chcesz przeprowadzić test na konkretnym docelowym obrazie systemu na rzeczywistym urządzeniu. Aby na przykład sprawdzić, czy jest to 64-bitowe urządzenie z architekturą ARM i interfejsem API Androida na poziomie 22:
ifeq ($(TARGET_ABI),android-22-arm64-v8a)
# ... do something ...
endif
Zmienne opisu modułu
Zmienne w tej sekcji opisują Twój moduł w systemie kompilacji. Każdy w opisie modułu:
- Zainicjuj lub cofnij zdefiniowanie zmiennych powiązanych z modułem za pomocą
Zmienna
CLEAR_VARS
. - Przypisanie wartości do zmiennych używanych do opisania modułu.
- Ustaw system kompilacji NDK tak, aby używał odpowiedniego skryptu kompilacji dla modułu.
za pomocą zmiennej
BUILD_XXX
.
LOCAL_PATH
Ta zmienna podaje ścieżkę bieżącego pliku. Musisz je zdefiniować
na początku pliku Android.mk
. Poniższy przykład pokazuje, jak to zrobić
czyli:
LOCAL_PATH := $(call my-dir)
Skrypt, na który wskazuje CLEAR_VARS
, nie odczytuje tej zmiennej. Dlatego
wystarczy zdefiniować go raz, nawet jeśli plik Android.mk
zawiera opis wielu modułów.
MODUŁ_LOKALNY
Ta zmienna przechowuje nazwę modułu. Musi być niepowtarzalna wśród wszystkich modułów
nazw i nie mogą zawierać spacji. Musisz je zdefiniować przed dodaniem
skrypty (inne niż dla CLEAR_VARS
). Nie musisz dodawać żadnego elementu: lib
lub rozszerzenie pliku .so
lub .a
; system kompilacji sprawia,
zmiany wprowadzane automatycznie. W okresie: Android.mk
i Application.mk
będą oznaczały moduł jego niezmodyfikowaną nazwą. Na przykład:
spowoduje wygenerowanie modułu biblioteki udostępnionej o nazwie libfoo.so
:
LOCAL_MODULE := "foo"
Jeśli chcesz, by wygenerowany moduł miał nazwę inną niż lib
+ wartość
LOCAL_MODULE
, możesz użyć zmiennej LOCAL_MODULE_FILENAME
, aby podać
nie może wygenerować modułu o wybranej przez Ciebie nazwie.
LOCAL_MODULE_FILENAME
Ta opcjonalna zmienna umożliwia zastępowanie nazw nadanych przez system kompilacji
domyślnie używa ich w generowanych plikach. Jeśli na przykład nazwa Twojego konta
LOCAL_MODULE
ma wartość foo
. Możesz wymusić na systemie wywołanie generowanego pliku
libnewfoo
Ten przykład ilustruje, jak to zrobić:
LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo
W przypadku modułu biblioteki udostępnionej ten przykład generuje plik o nazwie
libnewfoo.so
LOCAL_SRC_FILES
Ta zmienna zawiera listę plików źródłowych, których system kompilacji używa do
za wygenerowanie modułu. Wymieniaj tylko pliki przesyłane przez system kompilacji
do kompilatora, ponieważ system kompilacji automatycznie
zależności. Pamiętaj, że możesz używać zarówno wartości względnych (do LOCAL_PATH
), jak i bezwzględnych
ścieżek plików.
Zalecamy unikanie bezwzględnych ścieżek do plików. ścieżki względne sprawiają, że Android.mk
bardziej przenośny.
LOCAL_CPP_ROZSZERZENIE
Tej opcjonalnej zmiennej można użyć do wskazania rozszerzenia pliku innego niż
.cpp
na pliki źródłowe w C++. Na przykład ten wiersz zmienia
rozszerzenie do .cxx
. (ustawienie musi zawierać kropkę).
LOCAL_CPP_EXTENSION := .cxx
Za pomocą tej zmiennej możesz określać wiele rozszerzeń. Przykłady:
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
LOCAL_CPP_FEATURES
Za pomocą tej opcjonalnej zmiennej można wskazać, że kod zależy od
Funkcje C++. Włącza podczas kompilacji odpowiedni kompilator i flagi łączące
proces tworzenia konta. W przypadku gotowych plików binarnych ta zmienna deklaruje również funkcje
plików binarnych, od których zależy działanie ostatecznego połączenia. Śr
zalecamy używanie tej zmiennej zamiast włączania -frtti
i
-fexceptions
bezpośrednio w definicji LOCAL_CPPFLAGS
.
Użycie tej zmiennej pozwala systemowi kompilacji używać odpowiednich flag
każdego modułu. Użycie metody LOCAL_CPPFLAGS
powoduje, że kompilator używa wszystkich określonych
dla wszystkich modułów, niezależnie od
rzeczywistej potrzeby.
Aby na przykład wskazać, że Twój kod korzysta z RTTI (RunTime Type Information), zapis:
LOCAL_CPP_FEATURES := rtti
Aby wskazać, że w Twoim kodzie są używane wyjątki dotyczące języka C++, wpisz:
LOCAL_CPP_FEATURES := exceptions
Możesz też podać wiele wartości tej zmiennej. Na przykład:
LOCAL_CPP_FEATURES := rtti features
Kolejność, w jakiej opisujesz wartości, nie ma znaczenia.
LOCAL_C_INCLUDES
Za pomocą tej opcjonalnej zmiennej możesz określić listę ścieżek względem zmiennej
Katalog NDK root
, który ma zostać dodany do ścieżki uwzględniania wyszukiwania podczas kompilowania wszystkich
(C, C++ i Assembly). Na przykład:
LOCAL_C_INCLUDES := sources/foo
Albo nawet:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
Zdefiniuj tę zmienną, zanim ustawisz odpowiednie flagi uwzględniania za pomocą opcji
LOCAL_CFLAGS
lub LOCAL_CPPFLAGS
.
Podczas uruchamiania system kompilacji automatycznie używa też LOCAL_C_INCLUDES
ścieżek
na potrzeby debugowania natywnego, korzystając z ndk-gdb.
LOCAL_CFLAGS
Ta opcjonalna zmienna ustawia flagi kompilatora, które zostaną przekazane przez system kompilacji, gdy
dzięki utworzeniu plików źródłowych w języku C i C++. Możliwości te mogą okazać się przydatne
określając dodatkowe definicje makr lub opcje kompilacji. Użyj formatu: LOCAL_CPPFLAGS
w celu określenia flag tylko dla języka C++.
Postaraj się nie zmieniać poziomu optymalizacji i debugowania w pliku Android.mk
.
System kompilacji może obsłużyć to ustawienie automatycznie za pomocą
istotne informacje w pliku Application.mk
. Dzięki temu funkcja
do generowania przydatnych plików danych używanych podczas debugowania.
Dodatkowe ścieżki uwzględniania można określić, wpisując:
LOCAL_CFLAGS += -I<path>,
Do tego celu lepiej jednak używać parametru LOCAL_C_INCLUDES
, ponieważ
pozwala także używać ścieżek dostępnych
do debugowania natywnego,
ndk-gdb.
LOCAL_CPPFLAGS
Opcjonalny zestaw flag kompilatora, który będzie przekazywany podczas tworzenia źródła w C++
tylko pliki. Pojawią się po LOCAL_CFLAGS
na stronie kompilatora
wiersza poleceń. Użyj LOCAL_CFLAGS
, aby określić flagi zarówno w języku C, jak i C++.
LOCAL_STATIC_LIBRARIES
Ta zmienna przechowuje listę modułów bibliotek statycznych, w których bieżąca który zależy od modułu.
Jeśli bieżący moduł jest biblioteką współdzieloną lub plikiem wykonywalnym, ta zmienna wymusza połączenie tych bibliotek z wynikowym plikiem binarnym.
Jeżeli bieżący moduł to biblioteka statyczna, zmienna ta wskazuje po prostu, w zależności od bieżącego modułu zależą również od wymienionych biblioteki.
LOCAL_SHARED_LIBRARIES
Ta zmienna to lista modułów bibliotek udostępnionych, w których ten moduł zależy od środowiska wykonawczego. Te informacje są niezbędne w momencie utworzenia linku i po to, aby umieścić odpowiednie informacje w wygenerowanym pliku.
LOCAL_WHOLE_STATIC_LIBRARIES
Ta zmienna jest wariantem zmiennej LOCAL_STATIC_LIBRARIES
i wskazuje, że
tag łączący powinien traktować powiązane moduły biblioteki jako całe archiwa. Dla:
więcej informacji na temat całych archiwów znajdziesz w dokumentacji GNU ld
Flaga --whole-archive
.
Ta zmienna jest przydatna, gdy występują kołowe zależności między kilkoma bibliotek statycznych. Wykorzystasz tę zmienną do utworzenia udostępnionej biblioteki, wymuś dodanie przez system kompilacji wszystkich plików obiektów z bibliotek statycznych do końcowy plik binarny. Nie dotyczy to jednak plików wykonywalnych.
LOCAL_LDLIBS
Ta zmienna zawiera listę dodatkowych flag tagu łączącego, które można wykorzystać w tworzeniu
udostępnianej biblioteki lub pliku wykonywalnego. Umożliwia stosowanie prefiksu -l
do przekazywania
nazwy poszczególnych bibliotek systemowych. Poniższy przykład pokazuje,
tag łączący, aby wygenerować moduł łączący w czasie wczytywania z usługą /system/lib/libz.so
godzina:
LOCAL_LDLIBS := -lz
Dla listy ujawnionych bibliotek systemowych, do których można się połączyć w tym pliku NDK Więcej informacji znajdziesz w artykule na temat natywnych interfejsów API.
LOCAL_LDFLAGS
Lista innych flag tagu łączącego, których system kompilacji używa przy tworzeniu
udostępnianej biblioteki lub pliku wykonywalnego. Aby np. użyć tagu łączącego ld.bfd
na stronie
ARM/X86:
LOCAL_LDFLAGS += -fuse-ld=bfd
LOCAL_ALLOW_UNDEFINED_SYMBOLS
Domyślnie, gdy system kompilacji natrafi na niezdefiniowane odwołanie ale podczas próby utworzenia udostępnionego elementu wystąpi błąd niezdefiniowanego symbolu. Ten może pomóc w wykrywaniu błędów w kodzie źródłowym.
Aby wyłączyć sprawdzanie, ustaw tę zmienną na true
. Pamiętaj, że to ustawienie może
powoduje wczytanie biblioteki współdzielonej w czasie działania.
TRYB LOKALNY
Domyślnie system kompilacji generuje docelowe pliki binarne ARM w trybie kciuka,
gdzie każda instrukcja ma 16-bitową szerokość i jest powiązana z bibliotekami STL
Katalog thumb/
. Zdefiniowanie tej zmiennej jako arm
wymusza na systemie kompilacji
generowania plików obiektów modułu w 32-bitowym trybie arm
. Przykład poniżej
jak to zrobić:
LOCAL_ARM_MODE := arm
Możesz też polecić systemowi kompilacji tylko określone źródła w arm
przez dodanie sufiksu .arm
do nazw plików źródłowych. Na przykład parametr
Z tego przykładu dowiesz się, że system kompilacji zawsze kompiluje bar.c
w trybie ARM,
ale aby utworzyć foo.c
na podstawie wartości LOCAL_ARM_MODE
.
LOCAL_SRC_FILES := foo.c bar.c.arm
LOCAL_ARM_NEON
Ta zmienna ma znaczenie tylko wtedy, gdy kierujesz reklamy na interfejs ABI armeabi-v7a
. it
pozwala na użycie wbudowanych kompilatora ARM Advanced SIMD (NEON) w językach C i C++
oraz instrukcje NEON w plikach Asembly.
Pamiętaj, że nie wszystkie procesory z procesorami ARMv7 obsługują rozszerzenia zestawu instrukcji NEON. Z tego powodu, aby móc bezpiecznie używać ten kod w czasie działania. Aby dowiedzieć się więcej, zapoznaj się z informacjami na temat wsparcia Neon i Funkcje procesora.
Możesz też użyć sufiksu .neon
, aby określić, że system kompilacji
kompilować tylko określone pliki źródłowe z obsługą NEON. W poniższym przykładzie
system kompilacji kompiluje foo.c
z obsługą kciuków i neonów, bar.c
z obsługą kciuków i neonów
obsługa kciuków i zoo.c
z obsługą technologii ARM i NEON:
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
Jeśli używasz obu sufiksów, .arm
musi poprzedzać .neon
.
LOCAL_DISABLE_FORMAT_STRING_CHECKS
Domyślnie system kompilacji kompiluje kod z ochroną ciągu znaków formatu. Wykonuję
wymusza więc błąd kompilatora, jeśli w funkcji
Funkcja w stylu printf
. Ta ochrona jest domyślnie włączona, ale możesz ją wyłączyć
go, ustawiając wartość tej zmiennej na true
. Nie zalecamy tego
bez ważnego powodu.
LOCAL_EXPORT_CFLAGS
Ta zmienna rejestruje zestaw flag kompilatora C/C++, które należy dodać do interfejsu LOCAL_CFLAGS
.
każdego innego modułu, który korzysta z niego.
LOCAL_STATIC_LIBRARIES
lub LOCAL_SHARED_LIBRARIES
.
Przyjrzyjmy się np. następującej parze modułów: foo
i bar
, który
zależy od 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)
W tym przypadku system kompilacji przekazuje flagi -DFOO=1
i -DBAR=2
do kompilatora
podczas tworzenia bar.c
. Ten szablon dołącza też na początku wyeksportowanych flag do modułu
LOCAL_CFLAGS
, aby można je było łatwo zastąpić.
Dodatkowo relacja między modułami jest przechodni: jeśli zoo
zależy od
bar
, która z kolei zależy od parametru foo
, wtedy zoo
również dziedziczy wszystkie flagi
wyeksportowano z pliku foo
.
System kompilacji nie używa wyeksportowanych flag podczas kompilowania lokalnego
(np. tworząc moduł, którego flagi są eksportowane). W przykładzie
nie przekazuje pliku -DFOO=1
do kompilatora podczas kompilacji foo/foo.c
. Do
lokalnie, używaj zamiast tego LOCAL_CFLAGS
.
LOCAL_EXPORT_CPPFLAGS
Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS
, ale tylko w przypadku flag C++.
LOCAL_EXPORT_C_INCLUDES
Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS
, ale w przypadku C uwzględnij ścieżki. it
jest przydatny, gdy na przykład bar.c
musi zawierać nagłówki
moduł foo
.
LOCAL_EXPORT_LDFLAGS
Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS
, ale w przypadku flag tagu łączącego.
LOCAL_EXPORT_LDLIBS
Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS
i informuje system kompilacji, że
i przekazywać do kompilatora nazwy konkretnych bibliotek systemowych. Dołącz -l
na początku
każdej wskazanej biblioteki.
Zwróć uwagę, że system kompilacji dołącza zaimportowane flagi tagu łączącego do wartości parametru
zmiennej LOCAL_LDLIBS
modułu. Wynika to ze sposobu działania elementów łączących Unix.
Ta zmienna jest zwykle przydatna, gdy moduł foo
jest biblioteką statyczną i zawiera
który zależy od biblioteki systemowej. Następnie możesz użyć LOCAL_EXPORT_LDLIBS
do:
wyeksportować zależność. Na przykład:
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)
W tym przykładzie system kompilacji umieszcza -llog
na końcu polecenia łączącego
gdy tworzy libbar.so
. W ten sposób powiadomisz tag łączący, że libbar.so
w zależności od foo
, zależy też od systemowej biblioteki logów.
LOCAL_SHORT_POLECENIA
Ustaw tę zmienną na true
, jeśli Twój moduł ma bardzo dużą liczbę źródeł
lub zależnych bibliotek statycznych bądź udostępnionych. Wymusza to w systemie kompilacji
użyj składni @
w przypadku archiwów zawierających pośrednie pliki obiektów lub do połączeń
biblioteki.
Ta funkcja może być przydatna w systemie Windows, w którym wiersz poleceń akceptuje maksimum składające się z zaledwie 8191 znaków, co może być zbyt małe w przypadku złożonych projektów. Dodatkowo wpływa na kompilację poszczególnych plików źródłowych, przez co flagi także w plikach list.
Pamiętaj, że każda wartość inna niż true
zostanie przywrócone do działania domyślnego. Ty
można również zdefiniować zasadę APP_SHORT_COMMANDS
w pliku Application.mk
, aby wymusić
w obrębie wszystkich modułów w projekcie.
Nie zalecamy domyślnego włączania tej funkcji, ponieważ powoduje to, że kompilacja wolniej.
LOCAL_THIN_ARCHIVE
Podczas tworzenia bibliotek statycznych ustaw tę zmienną na true
. Jeśli to zrobisz,
wygenerować małe archiwum, czyli plik biblioteki, który nie zawiera plików obiektów,
ale zamiast tego tworzyć ścieżki do rzeczywistych obiektów, które normalnie
zawierają.
Pozwala to zmniejszyć rozmiar danych wyjściowych kompilacji. Wadą jest to, takich bibliotek nie można przenieść do innej lokalizacji (żadnych zawartych w nich ścieżek) są względne).
Prawidłowe wartości to true
, false
lub puste. Wartość domyślną można ustawić w
Application.mk
za pomocą zmiennej APP_THIN_ARCHIVE
.
LOCAL_FILTER_ASM
Zdefiniuj tę zmienną jako polecenie powłoki, którego system kompilacji będzie używać do filtrowania
pliki montażowe wyodrębnione lub wygenerowane z plików wskazanych przez Ciebie
LOCAL_SRC_FILES
Zdefiniowanie tej zmiennej powoduje następujące konsekwencje:
- System kompilacji generuje tymczasowy plik instalacyjny z dowolnego źródła w języku C lub C++. zamiast kompilować w pliku obiektowym.
- System kompilacji wykonuje polecenie powłoki w dokumencie
LOCAL_FILTER_ASM
na dowolnym tymczasowy plik montażowy oraz dowolny plik montażowy na liścieLOCAL_SRC_FILES
. w ten sposób i w ten sposób wygenerujemy kolejny tymczasowy plik asemblera. - System kompilacji kompiluje te przefiltrowane pliki zestawu do pliku obiektu.
Na przykład:
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” odpowiada kompilatorowi, „2” i „3” do asekuratora. Filtr musi być samodzielnym poleceniem powłoki, które przyjmuje nazwę danych wejściowych jako pierwszego argumentu, a nazwa pliku wyjściowego jako drugiego. Na przykład:
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
Makra funkcji udostępnione przez NDK
W tej sekcji opisano dostępne w programie NDK makra funkcji programu GNU Make. Używaj
$(call <function>)
, aby je ocenić; zwracają informacje tekstowe.
moj-katalog
To makro zwraca ścieżkę ostatniego uwzględnionego pliku Makefile, który zwykle jest
w bieżącym katalogu użytkownika Android.mk
. Funkcja my-dir
jest przydatna do określenia
LOCAL_PATH
na początku pliku Android.mk
. Na przykład:
LOCAL_PATH := $(call my-dir)
Ze względu na sposób działania GNU Make makro tak naprawdę zwraca ścieżkę
ostatni plik Makefile dołączonego przez system kompilacji podczas analizy skryptów kompilacji. Dla:
z tego powodu, nie należy wywoływać my-dir
po dołączeniu innego pliku.
Na przykład:
LOCAL_PATH := $(call my-dir)
# ... declare one module
include $(LOCAL_PATH)/foo/`Android.mk`
LOCAL_PATH := $(call my-dir)
# ... declare another module
Problem polega na tym, że drugie wywołanie funkcji my-dir
określa LOCAL_PATH
jako
$PATH/foo
zamiast $PATH
, bo tam właśnie ostatnio
szpiczastej.
Aby uniknąć tego problemu, umieść dodatkowe słowa ujęte po wszystkich pozostałych elementach.
w pliku Android.mk
. Na przykład:
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
Jeśli nie możesz tak skonstruować struktury pliku, zapisz wartość atrybutu
pierwsze wywołanie my-dir
do innej zmiennej. Na przykład:
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
all-subdir-makefiles
Zwraca listę plików Android.mk
znajdujących się we wszystkich podkatalogach funkcji
bieżąca ścieżka (my-dir
).
Za pomocą tej funkcji możesz umieścić głęboko zagnieżdżone hierarchie katalogów źródłowych w
w systemie kompilacji. Domyślnie NDK szuka tylko plików w katalogu
zawierający plik Android.mk
.
this-makefile
Zwraca ścieżkę bieżącego pliku Makefile (z którego system kompilacji wywołał funkcję ).
nadrzędny-makefile,
Zwraca ścieżkę nadrzędnego pliku Makefile w drzewie uwzględniania (ścieżka klucza programu Makefile zawierającego bieżący plik).
plik magistrali
Zwraca ścieżkę pliku Makefile nadrzędnego w drzewie uwzględniania (ścieżka w pliku Makefile dołączonego do bieżącego).
importuj moduł
Funkcja, która umożliwia znalezienie i dołączenie pliku Android.mk
modułu przez
nazwa modułu. Typowy przykład jest następujący:
$(call import-module,<name>)
W tym przykładzie system kompilacji szuka modułu oznaczonego tagiem <name>
lista katalogów, do których odwołuje się środowisko NDK_MODULE_PATH
do zmiennych i automatycznie dołącza jej plik Android.mk
.