בדף הזה מתואר התחביר של קובץ ה-build של Android.mk
שמשמש את
ndk-build
.
סקירה כללית
הקובץ Android.mk
נמצא בספריית משנה של jni/
של הפרויקט
ומתאר את המקורות והספריות המשותפות למערכת ה-build.
זה בעצם מקטע קטן של קובץ GNU שמערכת ה-build מנתחת פעם אחת,
עוד. הקובץ Android.mk
שימושי לקביעת הגדרות ברמת הפרויקט
Application.mk
, מערכת ה-build ומשתני הסביבה יוצאים
ולא מוגדר. היא גם יכולה לשנות הגדרות ברמת הפרויקט למודולים ספציפיים.
התחביר של Android.mk
מאפשר לקבץ את המקורות במודולים.
מודול הוא ספרייה סטטית, ספרייה משותפת או דף נפרד
קובץ הפעלה. אפשר להגדיר מודול אחד או יותר בכל קובץ Android.mk
, וגם
אתם יכולים להשתמש באותו קובץ מקור בכמה מודולים. רק מערכת ה-build
מציבה ספריות משותפות בחבילת האפליקציה שלך. בנוסף, סטטי
ספריות יכולות ליצור ספריות משותפות.
נוסף לספריות אריזה, מערכת ה-build מטפלת במגוון רחב של
עבורך. לדוגמה, לא צריך להציג קובצי כותרות או תוכן בוטה
של יחסי התלות בין הקבצים שנוצרו בקובץ Android.mk
. גרסת ה-build של NDK
המערכת מחשבת את הקשרים האלה בשבילכם באופן אוטומטי. כתוצאה מכך,
יוכלו להפיק תועלת מתמיכה חדשה בפלטפורמה או בצרור הכלים ב-NDK בעתיד
גרסאות בלי לגעת בקובץ Android.mk
.
התחביר של הקובץ הזה קרוב מאוד לזה שבו נעשה שימוש בקובצי Android.mk
שמופצת באמצעות פרויקט הקוד הפתוח המלא של Android. אומנם מערכת ה-build
שמשתמשת בהם שונה, הדמיון ביניהם
החלטה שנועדה להקל על מפתחי אפליקציות לעשות שימוש חוזר
את קוד המקור לספריות חיצוניות.
יסודות
לפני לחקור לעומק את התחביר, כדאי להתחיל בהבנה
את העקרונות הבסיסיים של קובץ Android.mk
. הקטע הזה משתמש
קובץ Android.mk
בדוגמת Hello-JNI למטרה הזו, עם הסבר על התפקיד
שמופעלת כל שורה בקובץ.
קובץ Android.mk
חייב להתחיל בהגדרת המשתנה LOCAL_PATH
:
LOCAL_PATH := $(call my-dir)
המשתנה הזה מציין את המיקום של קובצי המקור בפיתוח
עץ. כאן, פונקציית המאקרו my-dir
, שסופקה על ידי מערכת ה-build, מחזירה
הנתיב של הספרייה הנוכחית (הספרייה שמכילה את הפקודה Android.mk
בקובץ עצמו).
השורה הבאה מצהירה על המשתנה CLEAR_VARS
, שהערך שלו הוא מערכת ה-build
מספקת.
include $(CLEAR_VARS)
המשתנה CLEAR_VARS
מפנה לקובץ Makefile מיוחד של GNU שמנקה הרבה
LOCAL_XXX
משתנים עבורך, כמו LOCAL_MODULE
, LOCAL_SRC_FILES
ו
LOCAL_STATIC_LIBRARIES
לתשומת ליבכם: לא מתבצע ניקוי של LOCAL_PATH
. הזה
חייב לשמור על הערך שלו מפני שהמערכת מנתחת את כל הקבצים של בקרת ה-build
בהקשר ביצוע יחיד של GNU Make שבו כל המשתנים הם גלובליים. צריך
(להצהיר מחדש) על המשתנה הזה לפני התיאור של כל מודול.
לאחר מכן, המשתנה LOCAL_MODULE
שומר את שם המודול שרוצים לשמור
build. צריך להשתמש במשתנה הזה פעם אחת בכל מודול באפליקציה.
LOCAL_MODULE := hello-jni
כל שם מודול חייב להיות ייחודי ולא מכיל רווחים. מערכת ה-build,
כשהיא יוצרת את קובץ הספרייה המשותפת הסופי, מוסיפה באופן אוטומטי את
קידומת וסיומת לשם שהקצית ל-LOCAL_MODULE
. לדוגמה,
בדוגמה שמופיעה למעלה נוצרת ספרייה שנקראת
libhello-jni.so
השורה הבאה מסכמת את קובצי המקור, עם רווחים המפרידים מספר קובצי מקור קבצים:
LOCAL_SRC_FILES := hello-jni.c
המשתנה LOCAL_SRC_FILES
חייב להכיל רשימה של קובצי מקור מסוג C או C++
לפתח מודול במודול.
השורה האחרונה עוזרת למערכת לקשר הכול יחד:
include $(BUILD_SHARED_LIBRARY)
המשתנה BUILD_SHARED_LIBRARY
מפנה לסקריפט Makefile של GNU
שאוספת את כל המידע שהגדרתם ב-LOCAL_XXX
משתנים, כי
include
מהזמן האחרון. הסקריפט קובע מה ליצור ואיך לעשות אותו.
קיימות דוגמאות מורכבות יותר בספריות הדוגמאות עם הערות
Android.mk
קבצים שאפשר לצפות בהם. בנוסף, דוגמה: פעילות מותאמת
מספק הסבר מפורט לגבי הקובץ Android.mk
של הדוגמה. לבסוף,
הקטע משתנים ופקודות מאקרו מספק מידע נוסף על המשתנים
.
משתנים ופקודות מאקרו
מערכת ה-build מספקת משתנים אפשריים רבים לשימוש בקובץ Android.mk
.
רבים מהמשתנים האלה מגיעים עם ערכים שהוקצו מראש. את האחרים מקצים.
בנוסף למשתנים האלה תוכלו גם להגדיר שרירותיות משלכם. אם תעשה זאת, אל תמחק חשוב לזכור שמערכת ה-build של NDK שומרת את שמות המשתנים הבאים:
- שמות שמתחילים ב-
LOCAL_
, למשלLOCAL_MODULE
. - שמות שמתחילים ב-
PRIVATE_
, ב-NDK_
או ב-APP
. מערכת ה-build משתמשת אותם באופן פנימי. - שמות באותיות קטנות, כמו
my-dir
. מערכת ה-build משתמשת בהם באופן פנימי, נו.
אם אתם צריכים להגדיר משתני נוחות משלכם בקובץ Android.mk
,
מומלץ להוסיף את MY_
לשמות שלהם.
משתני הכללה שמוגדרים על ידי NDK
הקטע הזה מתאר את משתני ה-GNU ש-מערכת ה-build מגדירה
לפני ניתוח הקובץ Android.mk
. בנסיבות מסוימות, ה-NDK
יכול לנתח את קובץ Android.mk
כמה פעמים, תוך שימוש בהגדרה שונה
עבור חלק מהמשתנים האלה בכל פעם.
CLEAR_VARS
המשתנה הזה מפנה לסקריפט build שמגדיר כמעט את כל LOCAL_XXX
המשתנים שמפורטים בקטע "משתנים מוגדרים על ידי מפתחים" שבהמשך. שימוש בטיוטה הזו
כדי לכלול את הסקריפט לפני תיאור של מודול חדש. התחביר של
היא:
include $(CLEAR_VARS)
BUILD_EXECUTABLE
המשתנה הזה מפנה לסקריפט של build שאוסף את כל המידע על
המודול שסיפקתם במשתנים של LOCAL_XXX
, וקובע איך
ליצור קובץ יעד להפעלה מהמקורות שציינת. שימו לב שהשימוש
הסקריפט מחייב שכבר הקצית ערכים ל-LOCAL_MODULE
LOCAL_SRC_FILES
, לכל הפחות (למידע נוסף על המשתנים האלה, אפשר לעיין במאמר
משתנים של תיאור מודול).
התחביר לשימוש במשתנה הזה הוא:
include $(BUILD_EXECUTABLE)
BUILD_SHARED_LIBRARY
המשתנה הזה מפנה לסקריפט של build שאוסף את כל המידע על
המודול שסיפקתם במשתנים של LOCAL_XXX
, וקובע איך
ליצור ספריית יעד משותפת מהמקורות שציינת. שימו לב שהשימוש
הסקריפט מחייב שכבר הקצית ערכים ל-LOCAL_MODULE
LOCAL_SRC_FILES
, לכל הפחות (למידע נוסף על המשתנים האלה, אפשר לעיין במאמר
משתנים של תיאור מודול).
התחביר לשימוש במשתנה הזה הוא:
include $(BUILD_SHARED_LIBRARY)
משתנה של ספרייה משותפת גורם למערכת ה-build ליצור קובץ ספרייה
באמצעות סיומת .so
.
BUILD_staticIC_LIBRARY
וריאנט של BUILD_SHARED_LIBRARY
המשמש ליצירת ספרייה סטטית.
מערכת ה-build לא מעתיקה ספריות סטטיות לפרויקט/לחבילות שלכם, אלא
יכולים להשתמש בהם כדי ליצור ספריות משותפות (ראו LOCAL_STATIC_LIBRARIES
LOCAL_WHOLE_STATIC_LIBRARIES
, למטה). התחביר לשימוש במשתנה הזה הוא:
include $(BUILD_STATIC_LIBRARY)
משתנה ספרייה סטטית גורם למערכת ה-build ליצור ספרייה עם
התוסף .a
.
PREBUILT_SHARED_LIBRARY
מצביע על סקריפט build שמשמש לציון ספרייה משותפת שהוגדרה מראש. ביטול לייק ב:
במקרה של BUILD_SHARED_LIBRARY
ו-BUILD_STATIC_LIBRARY
, כאן הערך של
LOCAL_SRC_FILES
לא יכול להיות קובץ מקור. במקום זאת, הוא חייב להיות נתיב יחיד
ספרייה משותפת שהוגדרה מראש, כמו foo/libfoo.so
. התחביר לשימוש
הוא:
include $(PREBUILT_SHARED_LIBRARY)
תוכלו גם להפנות לספרייה שהוגדרה מראש במודול אחר באמצעות
משתנה LOCAL_PREBUILTS
. למידע נוסף על השימוש בנכסים מוכנים מראש,
שימוש בספריות מוכנות מראש.
PREBUILT_staticIC_LIBRARY
זהה ל-PREBUILT_SHARED_LIBRARY
, אבל לספרייה סטטית שהוגדרה מראש. עבור
למידע נוסף על השימוש בתבניות מוכנות מראש, אפשר לעיין במאמר שימוש בספריות מוכנות מראש.
משתני מידע יעד
מערכת ה-build מנתחת את Android.mk
פעם אחת לכל ממשק ABI שצוין ב-APP_ABI
שמוגדר בדרך כלל בקובץ Application.mk
. אם APP_ABI
הוא all
, אז מערכת ה-build מנתחת Android.mk
פעם אחת לכל ABI וה-NDK
נתמך. בקטע הזה מתוארים משתנים שמערכת ה-build מגדירה בכל פעם
מנתח את Android.mk
.
TARGET_ARCH
משפחת המעבדים (CPU) שמערכת ה-build מטרגטת בזמן שהיא מנתחת את Android.mk
חדש. המשתנה יהיה אחד מהערכים הבאים: arm
, arm64
, x86
או x86_64
.
TARGET_PLATFORM
המספר ברמת ה-API ב-Android שמערכת ה-build מטרגטת בזמן שהיא מנתחת את הנתונים האלה
קובץ Android.mk
. לדוגמה, תמונות המערכת של Android 5.1 מתאימות אל
רמת API ב-Android 22: android-22
. לרשימה מלאה של שמות הפלטפורמות
לתמונות המתאימות של המערכת של Android, ראו ממשקי API נייטיב.
הדוגמה הבאה מראה את התחביר לשימוש במשתנה הזה:
ifeq ($(TARGET_PLATFORM),android-22)
# ... do something ...
endif
TARGET_ARCH_ABI
ה-ABI שמערכת ה-build מטרגטת בזמן שהיא מנתחת את קובץ ה-Android.mk
הזה.
בטבלה 1 מוצגת הגדרת ה-ABI שמשמשת לכל ארכיטקטורה ומעבדים (CPU) נתמכים.
מעבד (CPU) וארכיטקטורה | הגדרה |
---|---|
ARMv7 | armeabi-v7a |
ARMv8 AArch64 | arm64-v8a |
i686 | x86 |
x86-64 | x86_64 |
בדוגמה הבאה אפשר לראות איך בודקים אם היעד ARMv8 AArch64 הוא ARMv8 AArch64 שילוב של מעבד (CPU) ו-ABI:
ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
# ... do something ...
endif
לפרטים נוספים על ממשקי ABI של ארכיטקטורה ובעיות תאימות משויכות, מידע נוסף זמין במאמר ממשקי ABI של Android.
לממשקי ABI חדשים לטירגוט יהיו ערכים שונים בעתיד.
TARGET_ABI
שרשור של רמת ה-API של Android לטירגוט ו-ABI. זה שימושי במיוחד כשרוצים לבצע בדיקה מול תמונת יעד ספציפית של מכשיר אמיתי. לדוגמה, כדי לחפש מכשיר ARM 64 ביט עם Android API ברמה 22:
ifeq ($(TARGET_ABI),android-22-arm64-v8a)
# ... do something ...
endif
משתנים של תיאור מודול
המשתנים בקטע הזה מתארים את המודול שלכם למערכת ה-build. כל אחד תיאור המודול צריך להתאים לתהליך הבסיסי הבא:
- לאתחל או לבטל את ההגדרה של המשתנים המשויכים למודול, באמצעות
משתנה
CLEAR_VARS
. - מקצים ערכים למשתנים שמשמשים לתיאור המודול.
- מגדירים את מערכת ה-build של NDK לשימוש בסקריפט ה-build המתאים למודול
באמצעות המשתנה
BUILD_XXX
.
LOCAL_PATH
המשתנה הזה משמש לקביעת הנתיב של הקובץ הנוכחי. צריך להגדיר אותה
בתחילת הקובץ Android.mk
. בדוגמה הבאה אפשר לראות איך לבצע
כך:
LOCAL_PATH := $(call my-dir)
הסקריפט שאליו נקודות CLEAR_VARS
לא מנקה את המשתנה הזה. לכן,
צריך להגדיר אותו פעם אחת בלבד, גם אם הקובץ Android.mk
מתאר מודולים מרובים.
LOCAL_MODULE
המשתנה הזה שומר את שם המודול שלכם. הוא חייב להיות ייחודי בכל המודולים
שמות, ולא יכולים להכיל רווחים. צריך להגדיר אותה לפני שכוללים טקסט
סקריפטים (חוץ מזה של CLEAR_VARS
). אין צורך להוסיף את lib
קידומת או סיומת הקובץ .so
או .a
; מערכת ה-build הופכת את
באופן אוטומטי. בכל Android.mk
ו-Application.mk
מתייחסים למודול לפי השם שבו לא בוצעו שינויים. לדוגמה,
התוצאה של יצירת מודול ספרייה משותפת בשם libfoo.so
:
LOCAL_MODULE := "foo"
אם רוצים שלמודול שנוצר יהיה שם שונה מ-lib
+ הערך של
LOCAL_MODULE
, אפשר להשתמש במשתנה LOCAL_MODULE_FILENAME
כדי לתת
שיצרנו עבורך שם לבחירתך.
LOCAL_MODULE_FILENAME
המשתנה האופציונלי הזה מאפשר לשנות את השמות ממערכת ה-build
משתמש כברירת מחדל בקבצים שהוא יוצר. לדוגמה, אם השם של
LOCAL_MODULE
הוא foo
. אפשר לאלץ את המערכת לקרוא לקובץ שהיא יוצרת
libnewfoo
. הדוגמה הבאה ממחישה איך לעשות זאת:
LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo
עבור מודול ספרייה משותפת, הדוגמה הזו תיצור קובץ בשם
libnewfoo.so
LOCAL_SRC_FILES
המשתנה הזה מכיל את רשימת קובצי המקור שמערכת ה-build משתמשת בהם כדי
היא ליצור את המודול. הצגת רשימה רק של הקבצים שמערכת ה-build מעבירה בפועל
מהדר, מכיוון שמערכת ה-build תחשב באופן אוטומטי את כל
של יחסי התלות. שימו לב שאפשר להשתמש גם ביחס ל-LOCAL_PATH
וגם במספר מוחלט
נתיבי קבצים.
מומלץ להימנע מנתיבי קבצים מוחלטים; הנתיבים היחסיים הופכים את Android.mk
יותר ניידות.
LOCAL_CPP_תוספים
ניתן להשתמש במשתנה האופציונלי הזה כדי לציין סיומת קובץ שאינה
.cpp
לקובצי המקור מסוג C++. לדוגמה, השורה הבאה משנה את
לתוסף ל-.cxx
. (ההגדרה חייבת לכלול את הנקודה).
LOCAL_CPP_EXTENSION := .cxx
ניתן להשתמש במשתנה הזה כדי לציין כמה תוספים. לדוגמה:
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
LOCAL_CPP_FEATURES
ניתן להשתמש במשתנה האופציונלי הזה כדי לציין שהקוד מסתמך על
תכונות C++. היא מפעילה את דגלי המהדר והקישור הנכונים במהלך ה-build.
תהליך האימות. לקבצים בינאריים מוכנים מראש, המשתנה הזה מצהיר גם אילו מהם כוללים
הבינארית תלויה, וכך היא עוזרת להבטיח שהקישור הסופי פועל כמו שצריך. רביעי
מומלץ להשתמש במשתנה הזה במקום להפעיל את -frtti
ואת
-fexceptions
ישירות בהגדרה של LOCAL_CPPFLAGS
.
שימוש במשתנה הזה מאפשר למערכת ה-build להשתמש בדגלים המתאימים
בכל מודול. שימוש ב-LOCAL_CPPFLAGS
גורם למהדר להשתמש בכל הפריטים שצוינו
דגלים בכל המודולים, ללא קשר לצורך בפועל.
לדוגמה, כדי לציין שהקוד משתמש ב-RTTI (RunTime Type Information), כתיבה:
LOCAL_CPP_FEATURES := rtti
כדי לציין שהקוד משתמש בחריגים של C++, כותבים:
LOCAL_CPP_FEATURES := exceptions
אפשר גם לציין כמה ערכים למשתנה הזה. לדוגמה:
LOCAL_CPP_FEATURES := rtti features
הסדר שבו מתארים את הערכים לא חשוב.
LOCAL_C_INCLUDES
ניתן להשתמש במשתנה האופציונלי הזה כדי לציין רשימה של נתיבים,
ספריית NDK root
, להוספה לנתיב החיפוש להכללה במהלך הידור של כל הפריטים
(C, C++ ו-Assembly). לדוגמה:
LOCAL_C_INCLUDES := sources/foo
או אפילו:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
צריך להגדיר את המשתנה הזה לפני שמגדירים סימוני הכללה תואמים באמצעות
LOCAL_CFLAGS
או LOCAL_CPPFLAGS
.
מערכת ה-build גם משתמשת בנתיבי LOCAL_C_INCLUDES
באופן אוטומטי בהפעלה
ניפוי באגים מקורי באמצעות ndk-gdb.
LOCAL_CFLAGS
המשתנה האופציונלי הזה מגדיר דגלי מהדר למערכת ה-build להעביר
פיתוח קובצי מקור וגם C++. היכולת לעשות זאת יכולה להועיל מאוד
לציון הגדרות מאקרו נוספות או אפשרויות הידור. שימוש בפורמט LOCAL_CPPFLAGS
כדי לציין דגלים עבור C++ בלבד.
מומלץ לא לשנות את רמת האופטימיזציה או ניפוי הבאגים בקובץ Android.mk
.
מערכת ה-build יכולה לטפל בהגדרה הזו בשבילך באופן אוטומטי באמצעות
מידע רלוונטי בקובץ Application.mk
. ככה עושים את זה,
build כדי ליצור קובצי נתונים שימושיים שמשמשים במהלך ניפוי באגים.
אפשר לציין נתיבי הכללה נוספים על ידי כתיבה:
LOCAL_CFLAGS += -I<path>,
עם זאת, עדיף להשתמש ב-LOCAL_C_INCLUDES
למטרה הזו, כי
הוא מאפשר גם להשתמש בנתיבים הזמינים לניפוי באגים מקורי עם
ndk-gdb.
LOCAL_CPPFLAGS
קבוצה אופציונלית של דגלי מהדר שיועברו במהלך פיתוח מקור C++
קבצים בלבד. הם יופיעו אחרי ה-LOCAL_CFLAGS
בחשבון המהדר
בשורת הפקודה. השתמשו ב-LOCAL_CFLAGS
כדי לציין דגלים גם ל-C וגם ל-C++.
LOCAL_staticIC_LIBRARIES
המשתנה הזה מאחסן את רשימת המודולים של הספריות הסטטיות שבהן תלוי.
אם המודול הנוכחי הוא ספרייה משותפת או קובץ הפעלה, המשתנה הזה לקשר את הספריות האלה לקובץ הבינארי שנוצר.
אם המודול הנוכחי הוא ספרייה סטטית, המשתנה פשוט מציין בהתאם למודול הנוכחי, תלויים גם הם של הספריות.
LOCAL_SHARED_LIBRARIES
המשתנה הזה הוא רשימת המודולים של הספריות המשותפות שבהן המודול הזה תלוי בזמן הריצה. המידע הזה נדרש בזמן הקישור, וכדי להטמיע את את המידע התואם בקובץ שנוצר.
LOCAL_WHOLE_staticIC_LIBRARIES
המשתנה הזה הוא וריאנט של LOCAL_STATIC_LIBRARIES
, והוא מציין
המקשר צריך להתייחס למודולים של הספריות המשויכים כארכיונים שלמים. עבור
ניתן למצוא מידע נוסף על ארכיונים שלמים במסמכי התיעוד של GNU ld
דגל --whole-archive
.
המשתנה הזה שימושי כאשר יש יחסי תלות מעגליים בין מספר של ספריות סטטיות. כשמשתמשים במשתנה הזה כדי לבנות ספרייה משותפת, הוא לאלץ את מערכת ה-build להוסיף את כל קובצי האובייקטים מהספריות הסטטיות הבינארית הסופית. עם זאת, הכלל הזה לא נכון גם כשיוצרים קובצי הפעלה.
LOCAL_LDLIBS
המשתנה הזה מכיל את רשימת דגלי הקישור הנוספים לשימוש בבניין
את הספרייה המשותפת או את קובץ ההפעלה. היא מאפשרת להשתמש בקידומת -l
כדי להעביר
השם של ספריות מערכת ספציפיות. לדוגמה, הדוגמה הבאה מראה
את המקשר כדי ליצור מודול שמקשר אל /system/lib/libz.so
בטעינה
שעה:
LOCAL_LDLIBS := -lz
לרשימה של ספריות המערכת החשופות שאפשר לקשר אליהן ב-NDK הזה שלו, ראו ממשקי API נייטיב.
LOCAL_LDFLAGS
רשימה של דגלים אחרים לקישור שבהם מערכת ה-build יכולה להשתמש במהלך הבנייה של
ספרייה משותפת או קובץ הפעלה. לדוגמה, כדי להשתמש במנגנון לקישור בין ld.bfd
ARM/X86:
LOCAL_LDFLAGS += -fuse-ld=bfd
LOCAL_ALLOW_UNDEFINED_SYMBOLS
כברירת מחדל, כשמערכת ה-build נתקלת בהפניה לא מוגדרת כשמנסים ליצור קובץ משותף, תקבלו שגיאת סמל לא מוגדר. הזה יכולה לעזור לכם לאתר באגים בקוד המקור.
כדי להשבית את הבדיקה הזו, צריך להגדיר את המשתנה הזה ל-true
. חשוב לשים לב שההגדרה הזו עשויה
תגרום לטעינת הספרייה המשותפת בזמן הריצה.
LOCAL_ARM_מצב
כברירת מחדל, מערכת ה-build יוצרת קבצים בינאריים של יעד ARM במצב תמונה ממוזערת,
כל הוראה היא ברוחב 16 סיביות ומקושרת לספריות ה-STL
ספריית thumb/
. הגדרת המשתנה הזה כ-arm
מאלצת את מערכת ה-build
ליצור את קובצי האובייקט של המודול במצב arm
32-ביט. הדוגמה הבאה
מראה כיצד לעשות זאת:
LOCAL_ARM_MODE := arm
אפשר גם להורות למערכת ה-build לבנות מקורות ספציפיים רק ב-arm
על ידי הוספת הסיומת .arm
לשמות הקבצים שבמקור. לדוגמה,
מהדוגמה הבאה אומרת למערכת ה-build תמיד לבצע הידור של bar.c
במצב ARM,
אלא לבנות את foo.c
בהתאם לערך של LOCAL_ARM_MODE
.
LOCAL_SRC_FILES := foo.c bar.c.arm
LOCAL_ARM_NEON
המשתנה הזה חשוב רק כשמטרגטים את ה-ABI של armeabi-v7a
. הוא
מאפשר להשתמש באלמנטים של מהדר (compiler) ARM Advanced SIMD (NEON) ב-C וב-C++
מקורות, וגם הוראות NEON בקובצי Assembly.
שימו לב שלא כל המעבדים (CPU) מבוססי ARMv7 תומכים בתוספים של קבוצת ההוראות של NEON. לכן, צריך לבצע זיהוי של סביבת זמן הריצה כדי להשתמש בצורה בטוחה את הקוד הזה בזמן הריצה. למידע נוסף, ראו תמיכה ב-Neon תכונות מעבד (CPU).
לחלופין, אפשר להשתמש בסיומת .neon
כדי לציין שמערכת ה-build.
הכינו רק קובצי מקור ספציפיים בתמיכה של NEON. בדוגמה הבאה,
מערכת ה-build יוצרת את foo.c
בעזרת תמיכה באצבע וניאון, bar.c
עם
תמיכה ב'אגודל', ו-zoo.c
עם תמיכה ב-ARM וב-NEON:
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
אם משתמשים בשתי הסיומות, .arm
חייב להקדים את .neon
.
LOCAL_DISABLE_FORMAT_STRING_CHECKS
כברירת מחדל, מערכת ה-build מהדרת קוד עם הגנה על מחרוזת פורמט. ביצוע
אז יאלץ שגיאת מהדר אם משתמשים במחרוזת בפורמט לא קבוע
פונקציה בסגנון printf
. ההגנה הזו מופעלת כברירת מחדל, אבל אפשר להשבית אותה
אותה על ידי הגדרת הערך של המשתנה הזה ל-true
. לא מומלץ לעשות זאת
ללא סיבה משכנעת.
LOCAL_EXPORT_CFLAGS
המשתנה הזה מתעד קבוצה של דגלי מהדר C/C++ שיש להוסיף אל LOCAL_CFLAGS
בהגדרה של כל מודול אחר שמשתמש בו דרך
משתנים של LOCAL_STATIC_LIBRARIES
או LOCAL_SHARED_LIBRARIES
.
לדוגמה, שימוש בצמד המודולים הבא: foo
ו-bar
,
תלוי ב-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)
כאן, מערכת ה-build מעבירה את הדגלים -DFOO=1
ו--DBAR=2
אל המהדר
כשבונים את bar.c
. הוא גם מצרף דגלים מיוצאים למודול של המודול
LOCAL_CFLAGS
כדי שתוכלו לשנות אותם בקלות.
בנוסף, הקשר בין המודולים הוא טרנזיטיבי: אם zoo
תלוי
bar
, שבתורו תלוי ב-foo
, zoo
גם יורש את כל הדגלים
יוצא מ-foo
.
לבסוף, מערכת ה-build לא משתמשת בדגלים מיוצאים בזמן הבנייה של גרסת ה-build באופן מקומי
(כלומר, בניית המודול שאת הדגלים שלו ניתן לייצא). כך שבדוגמה
שלמעלה, הוא לא מעביר את -DFOO=1
למהדר במהלך הבנייה של foo/foo.c
. שפת תרגום
לפתח באופן מקומי, להשתמש ב-LOCAL_CFLAGS
במקום זאת.
LOCAL_EXPORT_CPPFLAGS
המשתנה הזה זהה ל-LOCAL_EXPORT_CFLAGS
, אבל רק לדגלי C++.
LOCAL_EXPORT_C_INCLUDES
המשתנה הזה זהה ל-LOCAL_EXPORT_CFLAGS
, אבל במקרה של C יש לכלול נתיבים. הוא
שימושי במקרים שבהם, למשל, bar.c
צריך לכלול כותרות מ-
מודול foo
.
LOCAL_EXPORT_LDFLAGS
המשתנה הזה זהה ל-LOCAL_EXPORT_CFLAGS
, אבל עבור דגלים מסוג linker.
LOCAL_EXPORT_LDLIBS
המשתנה הזה זהה למשתנה LOCAL_EXPORT_CFLAGS
, והוא מנחה את מערכת ה-build
להעביר שמות של ספריות מערכת ספציפיות למהדר. מוסיפים את -l
בהתחלה
של כל ספרייה שציינתם.
שימו לב שמערכת ה-build מצרפת סימונים של מנגנון קישור מיובאים לערך של
במשתנה LOCAL_LDLIBS
של המודול. הסיבה לכך היא האופן שבו קישורי Unix פועלים.
המשתנה הזה שימושי בדרך כלל כאשר המודול foo
הוא ספרייה סטטית ויש לו
שתלוי בספריית מערכת. לאחר מכן אפשר להשתמש ב-LOCAL_EXPORT_LDLIBS
כדי
כדי לייצא את התלות. לדוגמה:
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)
בדוגמה הזו, מערכת ה-build מוסיפה את -llog
בסוף פקודת ה-linker
כשהוא יוצר את libbar.so
. הפעולה הזו אומרת למקשרים ש-libbar.so
תלוי ב-foo
, הוא תלוי גם בספריית הרישום ביומן של המערכת.
LOCAL_SHORT_CommandS
מגדירים את המשתנה הזה ל-true
כשבמודול יש מספר גבוה מאוד של מקורות
ו/או ספריות סטטיות או משותפות תלויות. הפעולה הזאת מאלצת את מערכת ה-build
להשתמש בתחביר @
לארכיונים שמכילים קובצי אובייקטים מתווכים או קישורים
של הספריות.
תכונה זו יכולה להיות שימושית ב-Windows, שבה שורת הפקודה מקבלת ערך מקסימלי של כולל רק 8,191 תווים, מה שעלול להיות קטן מדי לפרויקטים מורכבים. כמו כן משפיעה על האיסוף של קובצי מקור נפרדים, ולכן כמעט כל המהדר דגלים בתוך קובצי רשימה.
חשוב לזכור שכל ערך מלבד true
יחזור להתנהגות ברירת המחדל. שלך
יכול גם להגדיר APP_SHORT_COMMANDS
בקובץ Application.mk
כדי לאלץ
התנהגות זו בכל המודולים בפרויקט.
לא מומלץ להפעיל את התכונה הזו כברירת מחדל, כי היא הופכת את ה-build לאט יותר.
LOCAL_THIN_ARCHIVE
צריך להגדיר את המשתנה הזה כ-true
כשיוצרים ספריות סטטיות. הפעולה הזו תגרום
ליצור ארכיון דל, קובץ ספרייה שלא מכיל קובצי אובייקטים,
אלא רק נתיבים של קבצים לאובייקטים שבדרך כלל
מכילים.
האפשרות הזו שימושית כדי להקטין את הגודל של פלט ה-build. החיסרון הוא לא ניתן להעביר ספריות כאלו למיקום אחר (כל הנתיבים שבתוכן הם יחסיים).
הערכים החוקיים הם true
, false
או ריקים. ניתן להגדיר ערך ברירת מחדל בשדה
Application.mk
באמצעות המשתנה APP_THIN_ARCHIVE
.
LOCAL_FILTER_ASM
צריך להגדיר את המשתנה הזה כפקודת מעטפת שמערכת ה-build תשתמש בה כדי לסנן
קובצי ההרכבה שחולצו או נוצרו מהקבצים שציינת
LOCAL_SRC_FILES
הגדרת המשתנה הזה גורמת לשינויים הבאים:
- מערכת ה-build יוצרת קובץ הרכבה זמני מכל מקור מסוג C או C++ במקום להרכיב אותם לקובץ אובייקט.
- מערכת ה-build מריצים את פקודת המעטפת ב-
LOCAL_FILTER_ASM
בכל בקובץ הרכבה זמני ובכל קובץ הרכבה שרשום בכתובתLOCAL_SRC_FILES
, וכך ייווצר קובץ הרכבה זמני נוסף. - מערכת ה-build משלבת את קובצי ההרכבה המסוננים האלה לקובץ אובייקט.
לדוגמה:
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' תואם לרכיב המהדר, "2" למסנן, ו-"3" המסנן חייב להיות פקודת מעטפת עצמאית שמקבלת את שם הקלט בקובץ כארגומנט הראשון, ואת שם קובץ הפלט בתור הארגומנט השני. לדוגמה:
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
פקודות מאקרו של פונקציה שסופקה על ידי NDK
קטע זה מסביר את פקודות המאקרו של פונקציית GNU Make שה-NDK מספק. כדאי להשתמש
$(call <function>)
כדי להעריך אותם. הם מחזירים מידע טקסטואלי.
my-dir
המאקרו מחזיר את הנתיב של קובץ ה-makefile האחרון שנכלל, שלרוב
הספרייה של Android.mk
הנוכחית. my-dir
שימושי להגדרה
LOCAL_PATH
בתחילת הקובץ Android.mk
. לדוגמה:
LOCAL_PATH := $(call my-dir)
בשל אופן הפעולה של GNU Maker, המאקרו הזה באמת מחזיר את הנתיב
ה-Makefile האחרון שמערכת ה-build כללה במהלך ניתוח הסקריפטים של ה-build. עבור
לכן, אין לקרוא לפונקציה my-dir
אחרי שמוסיפים קובץ אחר.
לדוגמה:
LOCAL_PATH := $(call my-dir)
# ... declare one module
include $(LOCAL_PATH)/foo/`Android.mk`
LOCAL_PATH := $(call my-dir)
# ... declare another module
הבעיה כאן היא שהקריאה השנייה אל my-dir
מגדירה את LOCAL_PATH
כ-
$PATH/foo
במקום $PATH
, כי זה המקום שבו הגרסה האחרונה כוללת
מחודד.
אפשר להימנע מהבעיה הזו על ידי הוספת עוד 'הכללות' אחרי כל השאר
בקובץ Android.mk
. לדוגמה:
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
אם לא ניתן לבנות את הקובץ באופן הזה, שמור את הערך של
בקריאה הראשונה של my-dir
למשתנה אחר. לדוגמה:
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
קבצי מאכל-כל-subdir
הפונקציה מחזירה את הרשימה של Android.mk
קבצים שנמצאים בכל ספריות המשנה של
בנתיב my-dir
הנוכחי.
אפשר להשתמש בפונקציה הזו כדי לספק היררכיות של ספריות מקורות מוטמעות עמוקות,
במערכת ה-build. כברירת מחדל, ה-NDK מחפש רק קבצים בספרייה
שמכיל את הקובץ Android.mk
.
קובץ ה-makefile הזה
מחזירה את הנתיב של קובץ ה-getfile הנוכחי (שממנו מערכת ה-build קראה ).
קובץ הורה
מחזירה את הנתיב של קובץ ה-getfile של ההורה בעץ ההכללה (הנתיב של רכיב makefile שכלל את הקובץ הנוכחי).
קובץ סבא-סבתא
הפונקציה מחזירה את הנתיב של קובץ ה-Makefile הסב בעץ ההכללה (הנתיב של קובץ ה-Makefile שכלל את הקובץ הנוכחי).
מודול ייבוא
פונקציה שמאפשרת למצוא ולכלול את קובץ Android.mk
של המודול באמצעות
הוא שם המודול. דוגמה אופיינית היא:
$(call import-module,<name>)
בדוגמה זו, מערכת ה-build מחפשת את המודול שתויג ב-<name>
רשימת הספריות שסביבת NDK_MODULE_PATH
שלך מפנה אליהן
בהפניות למשתנים, וכוללת את קובץ ה-Android.mk
שלו באופן אוטומטי עבורכם.