Android.mk

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 bardzo mały fragment pliku make GNU, który system kompilacji analizuje raz lub więcej razy. 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 w całym projekcie w przypadku poszczególnych modułów.

Dzięki składni Android.mk możesz grupować źródła 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. System kompilacji umieszcza tylko 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 związku z tym w przyszłych wersjach NDK powinieneś mieć możliwość korzystania z nowej platformy lub łańcucha narzędzi w ramach obsługi NDK bez konieczności modyfikowania 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. Chociaż system kompilacji, który ich używa, jest inny, ich podobieństwo jest celowym projektem, którego celem jest ułatwienie deweloperom aplikacji ponowne wykorzystanie kodu źródłowego zewnętrznych bibliotek.

Podstawy

Zanim zaczniesz szczegółowo analizować składnię, warto najpierw poznać podstawy 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 się zaczynać od zdefiniowania zmiennej LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

Ta zmienna wskazuje lokalizację plików źródłowych w wersji deweloperskiej drzewo. Tutaj funkcja makro my-dir udostępniana przez system kompilacji zwraca ścieżkę do bieżącego katalogu (katalogu zawierającego sam plik Android.mk).

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 usuwa 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

Każda nazwa modułu musi być niepowtarzalna i nie może zawierać spacji. Gdy system kompilacji generuje ostateczny plik biblioteki współdzielonej, automatycznie dodaje odpowiedni prefiks i sufiks do nazwy przypisanej do LOCAL_MODULE. Na przykład przykład podany powyżej powoduje wygenerowanie biblioteki 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 C lub C++, które mają zostać skompilowane w moduł.

Ostatni wiersz pomaga systemowi połączyć wszystko w jedną całość:

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. Ten skrypt określa, co i jak budować.

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 przypisane wartości domyślne. a pozostałe – samodzielnie.

Oprócz tych zmiennych możesz też zdefiniować własne dowolne zmienne. W takim przypadku zachowaj pamiętaj, że system kompilacji NDK rezerwuje te nazwy zmiennych:

• Nazwy zaczynające się od LOCAL_, na przykład LOCAL_MODULE.
• Nazwy zaczynające się od PRIVATE_, NDK_ lub APP. System kompilacji używa ich 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 include zdefiniowane przez NDK

W tej sekcji omawiamy zmienne GNU Make, które system kompilacji definiuje przed przeanalizowaniem 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.

CLEAR_VARS

Ta zmienna wskazuje skrypt kompilacji, który odznacza prawie wszystkie zmienne LOCAL_XXX wymienione w sekcji „Zmienne zdefiniowane przez dewelopera”. Użyj tej zmiennej, aby uwzględnić ten skrypt przed opisem 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ć docelową bibliotekę współdzieloną 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_LIBRARY

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ż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życia tej zmiennej:

include $(PREBUILT_SHARED_LIBRARY)

Możesz też odwoływać się do gotowej biblioteki w innym module za pomocą zmiennej 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 wstępnie utworzonej biblioteki statycznej. Więcej informacji o korzystaniu z gotowych bibliotek znajdziesz w artykule Korzystanie z gotowych bibliotek.

Docelowe zmienne informacji

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 jest all, system kompilacji analizuje Android.mk raz na każdą wersję ABI obsługiwaną przez NDK. W tej sekcji opisano zmienne definiowane przez system kompilacji za każdym razem, analizuje element Android.mk.

TARGET_ARCH

Rodzina procesorów, na którą kierowany jest system kompilacji podczas analizowania tego zasobu (Android.mk) . Ta zmienna może mieć wartość 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ą poziomowi interfejsu API 22 w Androidzie: 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 zawiera ustawienie ABI używane w przypadku każdego obsługiwanego procesora i architektury.

Tabela 1. Ustawienia ABI dla różnych procesorów i architektur.

Ten przykład pokazuje, jak sprawdzić, czy ARMv8 AArch64 jest docelową kombinacją procesora i interfejsu ABI:

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

Więcej informacji o interfejsach ABI i powiązanych z nimi problemach ze zgodnością znajdziesz w artykule Interfejsy ABI na 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 sprawdzić, czy urządzenie z procesorem ARM 64-bitowym działa na poziomie API 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. Opis każdego modułu powinien być zgodny z tym podstawowym schematem:

1. Zainicjuj lub cofnij zdefiniowanie zmiennych powiązanych z modułem za pomocą Zmienna CLEAR_VARS.
2. Przypisz wartości do zmiennych używanych do opisu modułu.
3. 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 ją zdefiniować na początku pliku Android.mk. Ten przykład pokazuje, jak to zrobić:

LOCAL_PATH := $(call my-dir)

Skrypt, do którego odwołuje się CLEAR_VARS, nie czyści tej zmiennej. Dlatego wystarczy zdefiniować go raz, nawet jeśli plik Android.mk zawiera opis wielu modułów.

LOCAL_MODULE

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 ta linijka powoduje wygenerowanie modułu biblioteki współdzielonej 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ąpienie nazw, których system kompilacji używa domyślnie w przypadku generowanych plików. Jeśli na przykład nazwa LOCAL_MODULE to foo, możesz zmusić system do wywołania wygenerowanego przez niego 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 wygenerowania modułu. Wymień tylko pliki, które system kompilacji przekazuje kompilatorowi, ponieważ system kompilacji automatycznie oblicza wszystkie powiązane zależności. 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

Za pomocą tej opcjonalnej zmiennej możesz wskazać rozszerzenie pliku inne niż .cpp dla plików źródłowych 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ślić wiele rozszerzeń. Na przykład:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

Za pomocą tej opcjonalnej zmiennej możesz wskazać, że Twój kod korzysta z określonych funkcji C++. Włącza podczas kompilacji odpowiedni kompilator i flagi łączące proces tworzenia konta. W przypadku gotowych plików binarnych ta zmienna określa też, od których funkcji zależy ten plik binarny, co pomaga zapewnić prawidłowe działanie końcowego linkowania. Zalecamy użycie tej zmiennej zamiast włączania zmiennych -frtti i -fexceptions bezpośrednio w definicji LOCAL_CPPFLAGS.

Dzięki tej zmiennej system kompilacji może używać odpowiednich flag każdego modułu. Użycie opcji LOCAL_CPPFLAGS powoduje, że kompilator używa wszystkich określonych flag we wszystkich modułach niezależnie od rzeczywistych potrzeb.

Aby na przykład wskazać, że kod używa informacji o typie w czasie wykonywania (RTTI), napisz:

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ż określić dla niej kilka wartości. 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ą przed ustawieniem odpowiednich flag uwzględniania za pomocą funkcji LOCAL_CFLAGS lub LOCAL_CPPFLAGS.

System kompilacji automatycznie używa ścieżek LOCAL_C_INCLUDES podczas uruchamiania debugowania natywnego za pomocą ndk-gdb.

LOCAL_ASFLAGS

Flagi, które będą przekazywane do Clang podczas tworzenia plików .s lub .S.

LOCAL_ASMFLAGS

Flagi, które będą do Ciebie przekazywane podczas tworzenia plików .asm.

LOCAL_CFLAGS

Flagi, które będą przekazywane do języka Clang podczas tworzenia języka C, C++ i niektórych plików źródłowych zestawu (.s i .S, ale nie .asm). Ta funkcja może być przydatna do określania dodatkowych definicji makr lub opcji kompilacji. Użyj LOCAL_CPPFLAGS, aby określić flagi tylko dla języka C++. LOCAL_CONLYFLAGS – do określ flagi 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 system kompilacji może generować przydatne pliki danych używane podczas debugowania.

Dodatkowe ścieżki uwzględniania można określić, wpisując:

LOCAL_CFLAGS += -I<path>,

Lepiej jednak użyć do tego celu narzędzia LOCAL_C_INCLUDES, ponieważ umożliwia ono też korzystanie z ścieżek dostępnych do natywnego debugowania za pomocą ndk-gdb.

LOCAL_CONLYFLAGS

Flagi, które będą przekazywane do Clang podczas kompilacji źródeł C. W przeciwieństwie do LOCAL_CFLAGS zmienna LOCAL_CONLYFLAGS nie jest przekazywana do Clang podczas kompilowania źródeł C++ ani asemblera.

LOCAL_CPPFLAGS

Opcjonalny zestaw flag kompilatora, który zostanie przekazany podczas kompilowania tylko plików źródłowych C++. 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, od których zależy bieżący moduł.

Jeśli bieżący moduł jest biblioteką współdzieloną lub plikiem wykonywalnym, ta zmienna wymusza połączenie tych bibliotek z wynikowym plikiem binarnym.

Jeśli bieżący moduł jest statyczną biblioteką, ta zmienna wskazuje, że inne moduły, które zależą od bieżącego, będą też zależeć od wymienionych bibliotek.

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ą potrzebne w momencie łączenia i wstawiania odpowiednich informacji do wygenerowanego 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. Więcej informacji o całych archiwach znajdziesz w dokumentacji GNU ld dotyczącej flagi --whole-archive.

Ta zmienna jest przydatna, gdy występują kołowe zależności między kilkoma bibliotek statycznych. Gdy użyjesz tej zmiennej do skompilowania biblioteki współdzielonej, system kompilacji doda do końcowego pliku binarnego wszystkie pliki obiektowe z bibliotek statycznych. Nie dotyczy to jednak generowania 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 linkera dla systemu kompilacji, których należy używać podczas kompilowania biblioteki współdzielonej 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 napotka nieokreśloną referencję podczas próby skompilowania współdzielonego, wyrzuci błąd nieokreślony symbol. Ten może pomóc w wykrywaniu błędów w kodzie źródłowym.

Aby wyłączyć tę weryfikację, 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 pliki binarne docelowego ARM w trybie thumb, w którym każda instrukcja ma 16 bitów i jest powiązana z bibliotekami STL w katalogu thumb/. Zdefiniowanie tej zmiennej jako arm spowoduje, że system kompilacji wygeneruje pliki obiektów modułu w trybie 32-bitowym 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. Nie pozwala na używanie wbudowanych funkcji kompilatora ARM Advanced SIMD (NEON) w źródłach C i C++, a także instrukcji NEON w plikach asemblera.

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 wskazać, że system kompilacji ma kompilować tylko określone pliki źródłowe z obsługą NEON. W tym przykładzie system kompilacji kompiluje foo.c z obsługą funkcji thumb i neon, bar.c z obsługą funkcji thumb oraz zoo.c z obsługą architektury ARM i funkcji 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 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. Dodaje też do LOCAL_CFLAGS wyeksportowane flagi, dzięki czemu możesz je łatwo zastąpić.

Ponadto relacja między modułami jest przechodnia: jeśli zoo zależy od bar, który z kolei zależy od foo, to zoo dziedziczy również wszystkie flagi wyeksportowane z 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.

Pamiętaj, że system kompilacji dołącza zaimportowane flagi linkera do wartości zmiennej LOCAL_LDLIBS w module. 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

Jeśli moduł ma bardzo dużą liczbę źródeł lub zależnych bibliotek statycznych lub współdzielonych, ustaw tę zmienną na true. W ten sposób zmusisz system kompilacji do korzystania z składni @ w przypadku archiwów zawierających pośrednie pliki obiektów lub biblioteki linkowania.

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. Ma to również wpływ na kompilację poszczególnych plików źródłowych, ponieważ prawie wszystkie flagi kompilatora są umieszczane w plikach list.

Pamiętaj, że każda wartość inna niż true zostanie przywrócone do działania domyślnego. Możesz też zdefiniować parametr APP_SHORT_COMMANDS w pliku Application.mk, aby wymusić to zachowanie we wszystkich modułach 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żesz ustawić w pliku Application.mk za pomocą zmiennej APP_THIN_ARCHIVE.

LOCAL_FILTER_ASM

Zdefiniuj tę zmienną jako polecenie powłoki, którego system kompilacji użyje do odfiltrowania plików zestawu wyodrębnionych lub wygenerowanych z plików określonych w parametry LOCAL_SRC_FILES. Zdefiniowanie tej zmiennej powoduje następujące konsekwencje:

1. System kompilacji generuje tymczasowy plik asemblera z dowolnego pliku źródłowego C lub C++, zamiast kompilować go do pliku obiektowego.
2. System kompilacji wykonuje polecenie powłoki w pliku LOCAL_FILTER_ASM w przypadku każdego tymczasowego pliku assembly i każdego pliku assembly wymienionego w pliku LOCAL_SRC_FILES, generując w ten sposób kolejny tymczasowy plik assembly.
3. 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ępniane przez NDK

W tej sekcji opisano dostępne w programie NDK makra funkcji programu GNU Make. Użyj $(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żna uporządkować pliku w ten sposób, zapisz wartość pierwszego wywołania funkcji my-dir w 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ę ).

parent-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ę do pliku make w drzewie uwzględniania, który jest nadrzędnym bieżącego pliku make (ścieżkę do pliku make, który zawiera bieżący plik).

import-module

Funkcja, która umożliwia znalezienie i dołączenie pliku Android.mk modułu przez nazwa modułu. Typowy przykład:

$(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.