หน้านี้อธิบายไวยากรณ์ของไฟล์บิลด์ Android.mk
ที่ใช้โดย
ndk-build
ภาพรวม
ไฟล์ Android.mk
อยู่ในไดเรกทอรีย่อย jni/
ของโปรเจ็กต์
และอธิบายแหล่งที่มาและไลบรารีที่แชร์ไปยังระบบบิลด์
นี่เป็นส่วนย่อยของไฟล์ GNU ขนาดเล็กที่ระบบบิลด์จะแยกวิเคราะห์เพียงครั้งเดียวหรือ
และอีกมากมาย ไฟล์ Android.mk
มีประโยชน์สำหรับการกำหนดการตั้งค่าของทั้งโปรเจ็กต์ที่
Application.mk
ระบบบิลด์ และตัวแปรสภาพแวดล้อมจะปล่อยไว้
ไม่ได้กำหนด นอกจากนี้ยังลบล้างการตั้งค่าของทั้งโปรเจ็กต์สำหรับโมดูลที่เจาะจงได้ด้วย
ไวยากรณ์ของ Android.mk
ช่วยให้คุณจัดกลุ่มแหล่งที่มาเป็นโมดูลได้
โมดูลอาจเป็นไลบรารีแบบคงที่ ไลบรารีที่ใช้ร่วมกัน หรือสแตนด์อโลน
ไฟล์ปฏิบัติการ คุณสามารถกำหนดอย่างน้อย 1 โมดูลในไฟล์ Android.mk
แต่ละไฟล์ และ
คุณสามารถใช้ไฟล์ต้นฉบับเดียวกันในหลายโมดูลได้ ระบบบิลด์เท่านั้น
วางไลบรารีที่ใช้ร่วมกันไว้ในแพ็กเกจแอปพลิเคชัน นอกจากนี้
สามารถสร้างไลบรารีที่ใช้ร่วมกันได้
นอกเหนือจากไลบรารีบรรจุภัณฑ์แล้ว ระบบบิลด์ยังจัดการ
รายละเอียดให้คุณ เช่น คุณไม่จำเป็นต้องแสดงไฟล์ส่วนหัวหรือเนื้อหาที่อาจไม่เหมาะสม
ทรัพยากร Dependency ระหว่างไฟล์ที่สร้างขึ้นในไฟล์ Android.mk
บิลด์ NDK
ระบบจะคำนวณความสัมพันธ์เหล่านี้ให้คุณโดยอัตโนมัติ ด้วยเหตุนี้คุณ
จะได้รับประโยชน์จากการรองรับแพลตฟอร์ม/เชนเครื่องมือใหม่ในอนาคต NDK
ออกใหม่โดยไม่ต้องแตะไฟล์ Android.mk
ไวยากรณ์ของไฟล์นี้ใกล้เคียงกับที่ใช้ในไฟล์ Android.mk
มาก
แจกจ่ายด้วยโครงการโอเพนซอร์ส Android เต็มรูปแบบ ขณะที่ระบบบิลด์
ในการใช้งานจริงนั้นแตกต่างกัน ความคล้ายคลึงกันของทั้ง 2 แบบคือความตั้งใจ
การตัดสินใจออกแบบที่มุ่งให้นักพัฒนาแอปพลิเคชันสามารถนำ
ซอร์สโค้ดสำหรับไลบรารีภายนอก
ข้อมูลเบื้องต้น
ก่อนศึกษารายละเอียดไวยากรณ์ ควรเริ่มต้นด้วยการทำความเข้าใจ
ข้อมูลพื้นฐานในไฟล์ Android.mk
ส่วนนี้ใช้เมธอด
Android.mk
ในตัวอย่าง Hello-JNI ในด้านนั้น โดยอธิบายบทบาท
แต่ละบรรทัดในไฟล์จะเล่น
ไฟล์ Android.mk
ต้องเริ่มต้นด้วยการกำหนดตัวแปร LOCAL_PATH
ดังนี้
LOCAL_PATH := $(call my-dir)
ตัวแปรนี้ระบุตำแหน่งของไฟล์ต้นฉบับในการพัฒนา
ต้นไม้ ในที่นี้ ฟังก์ชันมาโคร my-dir
ซึ่งมาจากระบบบิลด์ จะส่งคืน
เส้นทางของไดเรกทอรีปัจจุบัน (ไดเรกทอรีที่มี Android.mk
โดยตรง)
บรรทัดถัดไปจะประกาศตัวแปร CLEAR_VARS
ซึ่งเป็นค่าของระบบบิลด์
ที่มีให้
include $(CLEAR_VARS)
ตัวแปร CLEAR_VARS
ชี้ไปที่ GNU Makefile พิเศษที่ช่วยล้างหลายๆ
ตัวแปร LOCAL_XXX
รายการให้คุณ เช่น LOCAL_MODULE
, LOCAL_SRC_FILES
และ
LOCAL_STATIC_LIBRARIES
โปรดทราบว่าไม่ล้างข้อมูล LOCAL_PATH
ช่วงเวลานี้
จะต้องเก็บค่าตัวแปรไว้เนื่องจากระบบแยกวิเคราะห์ไฟล์ควบคุมบิลด์ทั้งหมด
ใน GNU สร้างบริบทการดำเนินการที่ตัวแปรทั้งหมดอยู่ส่วนกลาง คุณต้อง
ประกาศตัวแปรนี้ (อีกครั้ง) ก่อนอธิบายแต่ละโมดูล
จากนั้นตัวแปร LOCAL_MODULE
จะจัดเก็บชื่อโมดูลที่คุณต้องการ
งานสร้าง ใช้ตัวแปรนี้ 1 ครั้งต่อโมดูลในแอปพลิเคชัน
LOCAL_MODULE := hello-jni
ชื่อโมดูลแต่ละชื่อต้องไม่ซ้ำกันและไม่มีการเว้นวรรค ระบบบิลด์
เมื่อสร้างไฟล์ไลบรารีที่ใช้ร่วมกันขั้นสุดท้าย ก็จะเพิ่มคอลัมน์
คำนำหน้าและคำต่อท้ายชื่อที่คุณกำหนดให้กับ LOCAL_MODULE
ตัวอย่างเช่น
ตัวอย่างที่ปรากฏด้านบนส่งผลให้เกิดการสร้างห้องสมุดชื่อ
libhello-jni.so
บรรทัดถัดไปจะแจกแจงไฟล์ต้นฉบับ โดยมีการเว้นวรรคคั่นไฟล์หลายรายการ ไฟล์:
LOCAL_SRC_FILES := hello-jni.c
ตัวแปร LOCAL_SRC_FILES
ต้องมีรายการไฟล์ต้นฉบับ C และ/หรือ C++
ในการสร้างเป็นโมดูล
บรรทัดสุดท้ายจะช่วยให้ระบบเชื่อมโยงทุกอย่างเข้าด้วยกัน
include $(BUILD_SHARED_LIBRARY)
ตัวแปร BUILD_SHARED_LIBRARY
ชี้ไปยังสคริปต์ GNU Makefile ที่
รวบรวมข้อมูลทั้งหมดที่คุณระบุไว้ในตัวแปร LOCAL_XXX
ตั้งแต่
include
ล่าสุด สคริปต์นี้จะกำหนดสิ่งที่ควรสร้างและวิธีสร้าง
มีตัวอย่างที่ซับซ้อนมากขึ้นในไดเรกทอรีตัวอย่าง โดยมีความคิดเห็น
Android.mk
ไฟล์ที่คุณสามารถดู นอกจากนี้ ตัวอย่าง: Native-activity
จะให้คำอธิบายโดยละเอียดเกี่ยวกับไฟล์ Android.mk
ของตัวอย่างดังกล่าว สุดท้าย
ตัวแปรและมาโครให้ข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรจาก
ตัวแปรและมาโคร
ระบบบิลด์มีตัวแปรที่เป็นไปได้หลายแบบสำหรับใช้ในไฟล์ Android.mk
ตัวแปรเหล่านี้จำนวนมากมาพร้อมกับค่าที่กำหนดไว้ล่วงหน้า ส่วนผู้อื่นคุณเป็นผู้มอบหมาย
นอกจากตัวแปรเหล่านี้แล้ว คุณยังกำหนดตัวแปรของคุณเองได้ด้วย หากเป็นเช่นนั้น โปรด โปรดทราบว่าระบบบิลด์ NDK จะสงวนชื่อตัวแปรต่อไปนี้:
- ชื่อที่ขึ้นต้นด้วย
LOCAL_
เช่นLOCAL_MODULE
- ชื่อที่ขึ้นต้นด้วย
PRIVATE_
,NDK_
หรือAPP
ระบบบิลด์ใช้ เหล่านี้เป็นการภายใน - ชื่อตัวพิมพ์เล็ก เช่น
my-dir
ระบบบิลด์จะใช้สิ่งเหล่านี้ภายใน
ถ้าคุณต้องกำหนดตัวแปรอำนวยความสะดวกของคุณเองในไฟล์ Android.mk
ขอแนะนำให้ใส่ MY_
ไว้หน้าชื่อ
ตัวแปรรวมที่กำหนดโดย NDK
ส่วนนี้จะกล่าวถึงตัวแปร GNU Make ที่ระบบกำหนด
ก่อนแยกวิเคราะห์ไฟล์ Android.mk
ในบางกรณี NDK
อาจแยกวิเคราะห์ไฟล์ Android.mk
หลายครั้งโดยใช้คำจำกัดความอื่น
สำหรับตัวแปรบางตัวทุกครั้ง
ล้างตัวแปร
ตัวแปรนี้ชี้ไปยังสคริปต์บิลด์ที่ยังไม่ได้กำหนด LOCAL_XXX
เกือบทั้งหมด
ตัวแปรที่แสดงใน "ตัวแปรที่นักพัฒนาแอปกำหนด" ด้านล่าง ใช้ร่างคำตอบนี้
ที่จะรวมสคริปต์นี้ก่อนที่จะอธิบายโมดูลใหม่ ไวยากรณ์ของ
โดยใช้สิ่งนี้
include $(CLEAR_VARS)
สร้างผลลัพธ์สำเร็จ
ตัวแปรนี้ชี้ไปยังสคริปต์บิลด์ที่รวบรวมข้อมูลทั้งหมดเกี่ยวกับ
โมดูลที่คุณระบุไว้ในตัวแปร LOCAL_XXX
รวมทั้งกำหนดวิธีการ
สร้างปฏิบัติการเป้าหมายจากแหล่งที่มาที่คุณระบุ โปรดทราบว่าการใช้สิ่งนี้
คุณต้องกำหนดค่าให้กับ LOCAL_MODULE
และ
LOCAL_SRC_FILES
เป็นอย่างน้อย (ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรเหล่านี้ได้ที่
ตัวแปรคำอธิบายโมดูล)
ไวยากรณ์สำหรับการใช้ตัวแปรนี้คือ
include $(BUILD_EXECUTABLE)
คลังที่ใช้ร่วมกัน
ตัวแปรนี้ชี้ไปยังสคริปต์บิลด์ที่รวบรวมข้อมูลทั้งหมดเกี่ยวกับ
โมดูลที่คุณระบุไว้ในตัวแปร LOCAL_XXX
รวมทั้งกำหนดวิธีการ
สร้างไลบรารีที่ใช้ร่วมกันเป้าหมายจากแหล่งที่มาที่คุณแสดงรายการไว้ โปรดทราบว่าการใช้สิ่งนี้
คุณต้องกำหนดค่าให้กับ LOCAL_MODULE
และ
LOCAL_SRC_FILES
เป็นอย่างน้อย (ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรเหล่านี้ได้ที่
ตัวแปรคำอธิบายโมดูล)
ไวยากรณ์สำหรับการใช้ตัวแปรนี้คือ
include $(BUILD_SHARED_LIBRARY)
ตัวแปรไลบรารีที่ใช้ร่วมกันจะทำให้ระบบบิลด์สร้างไฟล์ไลบรารี
ด้วยส่วนขยาย .so
คลังสถิติสถิติ
ตัวแปรของ BUILD_SHARED_LIBRARY
ที่ใช้สร้างไลบรารีแบบคงที่
ระบบบิลด์จะไม่คัดลอกไลบรารีแบบคงที่ไปยังโปรเจ็กต์/แพ็กเกจของคุณ แต่
สามารถใช้เพื่อสร้างไลบรารีที่ใช้ร่วมกันได้ (ดู LOCAL_STATIC_LIBRARIES
และ
LOCAL_WHOLE_STATIC_LIBRARIES
ด้านล่าง) ไวยากรณ์สำหรับการใช้ตัวแปรนี้คือ
include $(BUILD_STATIC_LIBRARY)
ตัวแปรไลบรารีแบบคงที่จะทำให้ระบบสร้างไลบรารีที่มี
ส่วนขยาย .a
คลังที่สร้างไว้ล่วงหน้า
ชี้ไปที่สคริปต์บิลด์ที่ใช้ระบุไลบรารีที่ใช้ร่วมกันที่สร้างไว้ล่วงหน้า เลิกชอบ
ในกรณีของ BUILD_SHARED_LIBRARY
และ BUILD_STATIC_LIBRARY
นี่คือค่าของ
LOCAL_SRC_FILES
ไม่สามารถเป็นไฟล์ต้นฉบับ แต่จะต้องเป็นเส้นทางเดียวเพื่อ
ไลบรารีที่ใช้ร่วมกันที่สร้างไว้ล่วงหน้า เช่น foo/libfoo.so
ไวยากรณ์ในการใช้
ตัวแปรคือ
include $(PREBUILT_SHARED_LIBRARY)
นอกจากนี้ คุณยังสามารถอ้างอิงไลบรารีที่สร้างไว้ล่วงหน้าในอีกโมดูลหนึ่งได้โดยใช้
ตัวแปร LOCAL_PREBUILTS
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้รายการที่สร้างไว้ล่วงหน้า โปรดดูที่
ใช้ไลบรารีที่สร้างไว้ล่วงหน้า
ไลบรารีสถิติเบื้องต้น
เหมือนกับ PREBUILT_SHARED_LIBRARY
แต่สำหรับไลบรารีแบบคงที่ที่สร้างไว้ล่วงหน้า สำหรับ
ข้อมูลเพิ่มเติมเกี่ยวกับการใช้รายการที่สร้างไว้ล่วงหน้า โปรดดูที่ใช้ไลบรารีที่สร้างไว้ล่วงหน้า
ตัวแปรข้อมูลเป้าหมาย
ระบบบิลด์จะแยกวิเคราะห์ Android.mk
1 ครั้งต่อ ABI ที่ระบุโดย APP_ABI
ซึ่งมักกำหนดไว้ในไฟล์ Application.mk
หาก APP_ABI
มีค่า all
ระบบบิลด์จะแยกวิเคราะห์ Android.mk
1 ครั้งต่อ ABI ส่วน NDK
รองรับ ส่วนนี้จะอธิบายตัวแปรที่ระบบบิลด์กำหนดทุกครั้งที่ระบบ
แยกวิเคราะห์ Android.mk
TARGET_ARCH
ตระกูล CPU ที่ระบบบิลด์กำหนดเป้าหมายขณะแยกวิเคราะห์ Android.mk
นี้
ตัวแปรนี้จะเป็น arm
, arm64
, x86
หรือ x86_64
TARGET_PLATFORM
หมายเลขระดับ API ของ Android ที่ระบบบิลด์กำหนดเป้าหมายขณะแยกวิเคราะห์
Android.mk
ไฟล์ ตัวอย่างเช่น อิมเมจระบบ Android 5.1 สอดคล้องกับ
API ของ Android ระดับ 22: android-22
หากต้องการดูรายชื่อแพลตฟอร์มทั้งหมดและ
อิมเมจระบบ Android ที่เกี่ยวข้อง โปรดดู Native API
ตัวอย่างต่อไปนี้แสดงไวยากรณ์สำหรับการใช้ตัวแปรนี้:
ifeq ($(TARGET_PLATFORM),android-22)
# ... do something ...
endif
TARGET_ARCH_ABI
ABI ที่ระบบบิลด์กำลังกำหนดเป้าหมายขณะแยกวิเคราะห์ไฟล์ Android.mk
นี้
ตารางที่ 1 แสดงการตั้งค่า ABI ที่ใช้สำหรับ CPU และสถาปัตยกรรมที่รองรับแต่ละรายการ
ตาราง 1 การตั้งค่า ABI สำหรับ CPU และสถาปัตยกรรมที่ต่างกัน
CPU และสถาปัตยกรรม | การเกริ่นนำ |
---|---|
ARMv7 | armeabi-v7a |
ARMv8 AArch64 | arm64-v8a |
I686 | x86 |
X86-64 | x86_64 |
ตัวอย่างต่อไปนี้แสดงวิธีตรวจสอบ 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
ตัวแปรคำอธิบายโมดูล
ตัวแปรในส่วนนี้จะอธิบายโมดูลของคุณให้กับระบบบิลด์ ชิ้น คำอธิบายโมดูลควรเป็นไปตามขั้นตอนพื้นฐานนี้
- เริ่มต้นหรือยกเลิกการกำหนดตัวแปรที่เชื่อมโยงกับโมดูล โดยใช้
ตัวแปร
CLEAR_VARS
- กำหนดค่าให้กับตัวแปรที่ใช้อธิบายโมดูล
- ตั้งค่าระบบบิลด์ NDK ให้ใช้สคริปต์บิลด์ที่เหมาะสมสำหรับโมดูล
โดยใช้ตัวแปร
BUILD_XXX
เส้นทาง LOCAL_PATH
ตัวแปรนี้ใช้เพื่อกำหนดเส้นทางของไฟล์ปัจจุบัน คุณต้องกำหนด
ที่จุดเริ่มต้นของไฟล์ Android.mk
ตัวอย่างต่อไปนี้จะแสดงวิธีการ
ดังนั้น:
LOCAL_PATH := $(call my-dir)
สคริปต์ที่ CLEAR_VARS
ชี้จะไม่ล้างตัวแปรนี้ ดังนั้น
คุณต้องกำหนดเพียงครั้งเดียวเท่านั้น ถึงแม้ว่าไฟล์ Android.mk
อธิบายโมดูลต่างๆ
โมดูลในพื้นที่
ตัวแปรนี้จัดเก็บชื่อโมดูลของคุณ ต้องไม่ซ้ำกันในทุกโมดูล
และต้องไม่มีการเว้นวรรค คุณต้องกำหนดก่อนที่จะรวม
สคริปต์ (นอกเหนือจากสคริปต์สำหรับ CLEAR_VARS
) คุณไม่จำเป็นต้องเพิ่ม lib
นำหน้าหรือนามสกุลไฟล์ .so
หรือ .a
ระบบบิลด์ทำให้
โดยอัตโนมัติ ตลอดทั้ง Android.mk
และ Application.mk
ให้อ้างอิงโมดูลด้วยชื่อที่ไม่มีการแก้ไข ตัวอย่างเช่น URL ต่อไปนี้
ผลลัพธ์บรรทัดในการสร้างโมดูลไลบรารีที่ใช้ร่วมกันชื่อ libfoo.so
:
LOCAL_MODULE := "foo"
หากคุณต้องการให้โมดูลที่สร้างมีชื่ออื่นที่ไม่ใช่ lib
+ ค่าของ
LOCAL_MODULE
คุณสามารถใช้ตัวแปร LOCAL_MODULE_FILENAME
เพื่อระบุฟิลด์
สร้างชื่อโมดูลที่คุณเลือกเองแทน
LOCAL_MODULE_FILENAME
ตัวแปรที่ไม่บังคับนี้ทำให้คุณสามารถลบล้างชื่อที่ระบบบิลด์
ใช้ค่าเริ่มต้นสำหรับไฟล์ที่สร้างขึ้นมา ตัวอย่างเช่น หากชื่อ
LOCAL_MODULE
คือ foo
คุณบังคับให้ระบบเรียกไฟล์ที่ระบบสร้างได้
libnewfoo
ตัวอย่างต่อไปนี้แสดงวิธีดำเนินการดังกล่าว
LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo
สำหรับโมดูลไลบรารีที่ใช้ร่วมกัน ตัวอย่างนี้จะสร้างไฟล์ชื่อ
libnewfoo.so
LOCAL_SRC_FILES
ตัวแปรนี้มีรายการไฟล์ต้นฉบับที่ระบบบิลด์ใช้เพื่อ
สร้างโมดูลนี้ แสดงเฉพาะไฟล์ที่ระบบบิลด์ผ่านจริงๆ เท่านั้น
ไปยังคอมไพเลอร์ เนื่องจากระบบบิลด์จะคำนวณ
ทรัพยากร Dependency โปรดทราบว่าคุณสามารถใช้ทั้งแบบสัมพัทธ์ (กับ LOCAL_PATH
) และสัมบูรณ์
เส้นทางไฟล์
เราขอแนะนำให้หลีกเลี่ยงเส้นทางไฟล์แบบสัมบูรณ์ เส้นทางสัมพัทธ์จะทำให้ Android.mk
ไฟล์สามารถพกพาได้มากขึ้น
LOCAL_CPP_EXTENSION
คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุนามสกุลไฟล์นอกเหนือจาก
.cpp
สำหรับไฟล์ต้นฉบับ C++ ตัวอย่างเช่น บรรทัดต่อไปนี้จะเปลี่ยน
ส่วนขยายไปยัง .cxx
(การตั้งค่าต้องมีจุด)
LOCAL_CPP_EXTENSION := .cxx
คุณใช้ตัวแปรนี้เพื่อระบุส่วนขยายหลายรายการได้ ตัวอย่างเช่น
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
ฟีเจอร์ LOCAL_CPP
คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุว่าโค้ดของคุณใช้ตัวแปร
C++ ช่วยให้มีการแฟล็กคอมไพเลอร์และ Linker ที่เหมาะสมระหว่างบิลด์
ขั้นตอนได้ สำหรับไบนารีที่สร้างไว้ล่วงหน้า ตัวแปรนี้จะประกาศฟีเจอร์
จะขึ้นอยู่กับว่าลิงก์สุดท้ายทำงานได้อย่างถูกต้อง พ
ขอแนะนำให้คุณใช้ตัวแปรนี้แทนการเปิดใช้ -frtti
และ
-fexceptions
โดยตรงในคำจำกัดความ LOCAL_CPPFLAGS
การใช้ตัวแปรนี้ช่วยให้ระบบบิลด์ใช้แฟล็กที่เหมาะสมสำหรับ
แต่ละโมดูล การใช้ LOCAL_CPPFLAGS
จะทำให้คอมไพเลอร์ใช้ทุกรายการที่ระบุไว้
สำหรับทุกโมดูล โดยไม่คำนึงถึงความต้องการจริง
เช่น เพื่อระบุว่าโค้ดของคุณใช้ RTTI (ข้อมูลประเภทรันไทม์) เขียน:
LOCAL_CPP_FEATURES := rtti
หากต้องการระบุว่าโค้ดของคุณใช้ข้อยกเว้น C++ ให้เขียนดังนี้
LOCAL_CPP_FEATURES := exceptions
คุณสามารถระบุหลายค่าสำหรับตัวแปรนี้ได้เช่นกัน เช่น
LOCAL_CPP_FEATURES := rtti features
ลำดับที่คุณอธิบายค่านั้นไม่สำคัญ
Local_C_INCLUDES
คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุรายการเส้นทางที่สัมพันธ์กับ
ไดเรกทอรี root
ของ NDK เพื่อเพิ่มไปยังเส้นทางการค้นหาเมื่อรวบรวมข้อมูลทั้งหมด
แหล่งที่มา (C, C++ และ Assembly) เช่น
LOCAL_C_INCLUDES := sources/foo
หรือแม้กระทั่ง:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
กำหนดตัวแปรนี้ก่อนตั้งค่าแฟล็กการรวมที่เกี่ยวข้องผ่าน
LOCAL_CFLAGS
หรือ LOCAL_CPPFLAGS
ระบบบิลด์ยังใช้เส้นทาง LOCAL_C_INCLUDES
โดยอัตโนมัติเมื่อเปิดตัวด้วย
การแก้ไขข้อบกพร่องของระบบด้วย ndk-gdb
LOCAL_CFLAGS
ตัวแปรที่ไม่บังคับนี้ตั้งค่าแฟล็กคอมไพเลอร์เพื่อให้ระบบบิลด์ส่งต่อเมื่อ
สร้างไฟล์ C และไฟล์ต้นฉบับ C++ ความสามารถในการดำเนินการข้างต้น มีประโยชน์สำหรับ
โดยระบุคำจำกัดความของมาโครเพิ่มเติมหรือคอมไพล์ตัวเลือก ใช้ LOCAL_CPPFLAGS
เพื่อระบุแฟล็กสำหรับ C++ เท่านั้น
พยายามอย่าเปลี่ยนระดับการเพิ่มประสิทธิภาพ/การแก้ไขข้อบกพร่องในไฟล์ Android.mk
ระบบบิลด์สามารถจัดการการตั้งค่านี้ให้คุณโดยอัตโนมัติ โดยใช้
ข้อมูลที่เกี่ยวข้องในไฟล์ Application.mk
การทำเช่นนี้ช่วยให้
ระบบบิลด์เพื่อสร้างไฟล์ข้อมูลที่เป็นประโยชน์ซึ่งใช้ในระหว่างการแก้ไขข้อบกพร่อง
คุณสามารถระบุเส้นทางรวมเพิ่มเติมได้ด้วยการเขียนดังนี้
LOCAL_CFLAGS += -I<path>,
อย่างไรก็ตาม การใช้ LOCAL_C_INCLUDES
เพื่อวัตถุประสงค์นี้จะดีกว่า เนื่องจาก
จึงทำให้สามารถใช้เส้นทางที่มีอยู่สำหรับการแก้ไขข้อบกพร่องของระบบด้วย
ndk-gdb
LOCAL_CPPFLAGS
ชุดแฟล็กคอมไพเลอร์ที่ไม่บังคับซึ่งจะส่งผ่านเมื่อสร้างซอร์ส C++
เท่านั้น โดยจะปรากฏหลัง LOCAL_CFLAGS
ใน
บรรทัดคำสั่ง ใช้ LOCAL_CFLAGS
เพื่อระบุแฟล็กสำหรับทั้ง C และ C++
ไลบรารี LOCAL_STATIC_LIBRARIES
ตัวแปรนี้จัดเก็บรายการโมดูลไลบรารีแบบคงที่ซึ่งฟังก์ชัน ขึ้นอยู่กับ
หากโมดูลปัจจุบันเป็นไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการ ตัวแปรนี้จะ บังคับให้ไลบรารีเหล่านี้เชื่อมโยงกับไบนารีที่ได้
หากโมดูลปัจจุบันเป็นไลบรารีแบบคงที่ ตัวแปรนี้เพียงแค่ระบุว่า โมดูลอื่นๆ ที่ขึ้นอยู่กับโมดูลปัจจุบัน จะขึ้นอยู่กับโมดูล ห้องสมุด
ห้องสมุด LOCAL_SHARED_LIBRARIES
ตัวแปรนี้คือรายการโมดูลไลบรารีที่ใช้ร่วมกันซึ่งโมดูลนี้ใช้อยู่ ขึ้นอยู่กับรันไทม์ ข้อมูลนี้เป็นสิ่งจำเป็นในเวลาที่ลิงก์ และเพื่อฝัง ข้อมูลที่เกี่ยวข้องในไฟล์ที่สร้างขึ้น
ไลบรารี LOCAL_WHOLE_STATIC_LIBRARIES
ตัวแปรนี้เป็นตัวแปรของ LOCAL_STATIC_LIBRARIES
และแสดงให้เห็นว่าฟังก์ชัน
Linker ควรถือว่าโมดูลไลบรารีที่เกี่ยวข้องเป็นที่เก็บถาวรทั้งหมด สำหรับ
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับที่เก็บถาวรทั้งหมด โปรดดูเอกสารประกอบของ GNU ld สำหรับ
แฟล็ก --whole-archive
ตัวแปรนี้มีประโยชน์เมื่อมีทรัพยากร Dependency แบบวงกลมจากหลายๆ กลุ่ม และไลบรารีแบบคงที่ เมื่อคุณใช้ตัวแปรนี้เพื่อสร้างไลบรารีที่ใช้ร่วมกัน ระบบจะ บังคับให้ระบบบิลด์เพิ่มไฟล์ออบเจ็กต์ทั้งหมดจากไลบรารีแบบคงที่ไปยังไฟล์ เลขฐานสองสุดท้าย อย่างไรก็ตาม จะไม่เป็นความจริงเมื่อสร้างไฟล์ปฏิบัติการ
LOCAL_LDLIBS
ตัวแปรนี้มีรายการแฟล็ก Linker เพิ่มเติมสำหรับใช้ในอาคาร
ไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการของคุณ ซึ่งช่วยให้คุณใช้คำนำหน้า -l
เพื่อส่งผ่านได้
ชื่อของไลบรารีระบบที่เฉพาะเจาะจง ตัวอย่างเช่น ตัวอย่างต่อไปนี้บอก
Linker เพื่อสร้างโมดูลที่ลิงก์ไปยัง /system/lib/libz.so
ขณะโหลด
เวลา:
LOCAL_LDLIBS := -lz
สำหรับรายการไลบรารีระบบที่เปิดเผยซึ่งคุณลิงก์ใน NDK นี้ได้ โปรดดู Native API
LOCAL_LDFLAGS
รายการแฟล็ก Linker อื่นๆ สำหรับระบบบิลด์เพื่อใช้เมื่อสร้าง
ไลบรารีหรือไฟล์สั่งการที่ใช้ร่วมกัน เช่น หากต้องการใช้ตัวลิงก์ ld.bfd
ใน
ARM/X86:
LOCAL_LDFLAGS += -fuse-ld=bfd
LOCAL_ALLOW_UNDEFINED_SYMBOLS
โดยค่าเริ่มต้น เมื่อระบบบิลด์พบการอ้างอิงที่ไม่ได้กำหนด ขณะที่พยายามสร้างการแชร์ ก็จะเกิดข้อผิดพลาดเกี่ยวกับสัญลักษณ์ที่ไม่ระบุ ช่วงเวลานี้ สามารถช่วยให้พบข้อบกพร่องในซอร์สโค้ด
หากต้องการปิดใช้การตรวจสอบนี้ ให้ตั้งค่าตัวแปรนี้เป็น true
โปรดทราบว่าการตั้งค่านี้อาจ
ทำให้ไลบรารีที่ใช้ร่วมกันโหลดขณะรันไทม์
โหมด LOCAL_ARM
โดยค่าเริ่มต้น ระบบบิลด์จะสร้างไบนารีเป้าหมาย ARM ในโหมดภาพขนาดย่อ
โดยแต่ละคำสั่งจะมีความกว้าง 16 บิตและเชื่อมโยงกับไลบรารี STL ใน
ไดเรกทอรี thumb/
การกำหนดตัวแปรนี้เป็น arm
จะบังคับให้ระบบบิลด์
สร้างไฟล์ออบเจ็กต์ของโมดูลในโหมด arm
แบบ 32 บิต ตัวอย่างต่อไปนี้
แสดงวิธีดำเนินการ
LOCAL_ARM_MODE := arm
หรือจะสั่งให้ระบบบิลด์สร้างเฉพาะแหล่งที่มาที่เฉพาะเจาะจงใน arm
ก็ได้
โดยเพิ่ม .arm
ต่อท้ายชื่อไฟล์ต้นฉบับ ตัวอย่างเช่น พารามิเตอร์
ตัวอย่างต่อไปนี้จะบอกระบบบิลด์ให้คอมไพล์ bar.c
ในโหมด ARM เสมอ
แต่เพื่อสร้าง foo.c
ตามค่าของ LOCAL_ARM_MODE
LOCAL_SRC_FILES := foo.c bar.c.arm
LOCAL_ARM_NEON
ตัวแปรนี้สําคัญเฉพาะเมื่อคุณกําหนดเป้าหมาย ABI armeabi-v7a
เท่านั้น ทั้งนี้
อนุญาตให้ใช้คอมไพเลอร์ของ ARM Advanced SIMD (NEON) ใน C และ C++ ได้
รวมทั้งคำสั่ง NEON ในไฟล์ Assembly ด้วย
โปรดทราบว่า CPU ที่ใช้ ARMv7 บางรุ่นไม่รองรับส่วนขยายชุดคำสั่ง NEON ด้วยเหตุนี้ คุณจึงต้องตรวจหารันไทม์เพื่อให้ใช้ได้อย่างปลอดภัย โค้ดนี้ขณะรันไทม์ สำหรับข้อมูลเพิ่มเติม โปรดดูที่การสนับสนุนของ Neon และ ฟีเจอร์ของ CPU
หรือคุณจะใช้ส่วนต่อท้าย .neon
เพื่อระบุว่าระบบบิลด์ก็ได้
คอมไพล์ไฟล์ต้นฉบับที่มีการรองรับ NEON เท่านั้น ในตัวอย่างต่อไปนี้
ระบบบิลด์คอมไพล์ foo.c
พร้อมการรองรับนิ้วโป้งและนีออน bar.c
ด้วย
รองรับนิ้วหัวแม่มือ และ zoo.c
พร้อมการรองรับ ARM และ NEON:
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
หากคุณใช้คำต่อท้ายทั้ง 2 แบบ .arm
ต้องมาก่อน .neon
LOCAL_DISABLE_FORMAT_STRING_CHECKS
โดยค่าเริ่มต้น ระบบบิลด์จะรวบรวมโค้ดพร้อมด้วยการป้องกันสตริงรูปแบบ กำลังทำ
ซึ่งจะบังคับให้เกิดข้อผิดพลาดของคอมไพเลอร์ หากใช้สตริงรูปแบบที่ไม่คงที่ในองค์ประกอบ
ฟังก์ชันแบบ 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)
ในส่วนนี้ ระบบบิลด์จะส่งแฟล็ก -DFOO=1
และ -DBAR=2
ไปยังคอมไพเลอร์
เมื่อสร้างbar.c
นอกจากนี้ยังเพิ่ม Flag ที่ส่งออกไว้หน้า Flag ของโมดูลของคุณ
LOCAL_CFLAGS
เพื่อให้คุณลบล้างค่าได้อย่างง่ายดาย
นอกจากนี้ ความสัมพันธ์ระหว่างโมดูลต่างๆ เป็นแบบทรานซิทีฟ: หาก zoo
ขึ้นอยู่กับ
bar
ซึ่งก็ขึ้นอยู่กับ foo
แล้ว zoo
จะรับค่า Flag ทั้งหมดด้วย
ส่งออกจาก foo
สุดท้าย ระบบบิลด์ไม่ได้ใช้ Flag ที่ส่งออกเมื่อสร้างในเครื่อง
(เช่น การสร้างโมดูลที่มีการส่งออกธง) ดังนั้นในตัวอย่าง
ด้านบน จะไม่ส่ง -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
บอกให้ระบบบิลด์
ส่งผ่านชื่อของไลบรารีระบบที่เฉพาะเจาะจงไปยังคอมไพเลอร์ แทรก -l
ไว้ข้างหน้า
ของไลบรารีแต่ละรายการที่คุณระบุ
โปรดทราบว่าระบบบิลด์จะเพิ่มแฟล็ก Linker ที่นำเข้าต่อท้ายค่าของ
ตัวแปร LOCAL_LDLIBS
ของโมดูล เนื่องจากวิธีการทํางานของ Unix Linker
โดยทั่วไป ตัวแปรนี้จะมีประโยชน์เมื่อโมดูล foo
เป็นไลบรารีแบบคงที่และมี
ที่ขึ้นอยู่กับไลบรารีของระบบ จากนั้นคุณสามารถใช้ LOCAL_EXPORT_LDLIBS
เพื่อ
เพื่อส่งออกทรัพยากร Dependency เช่น
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)
ในตัวอย่างนี้ ระบบบิลด์จะใส่ -llog
ไว้ที่ท้ายคำสั่ง Linker
เมื่อสร้าง libbar.so
การทำเช่นนี้จะบอกให้ Linker ทราบว่า เนื่องจาก libbar.so
ขึ้นอยู่กับ foo
และยังขึ้นอยู่กับไลบรารีการบันทึกของระบบด้วย
LOCAL_SHORT_COMMAND
ตั้งค่าตัวแปรนี้เป็น true
เมื่อโมดูลมีแหล่งที่มาสูงมาก
และ/หรือไลบรารีแบบคงที่หรือไลบรารีที่ใช้ร่วมกันไม่ได้ การทำเช่นนี้จะบังคับให้ระบบบิลด์
ใช้ไวยากรณ์ @
สำหรับที่เก็บถาวรที่มีไฟล์ออบเจ็กต์สื่อกลางหรือการลิงก์
ห้องสมุด
ฟีเจอร์นี้อาจมีประโยชน์ใน Windows ซึ่งบรรทัดคำสั่งยอมรับจำนวนสูงสุด โดยใช้อักขระเพียง 8, 191 ตัว ซึ่งอาจเล็กเกินไปสำหรับโปรเจ็กต์ที่ซับซ้อน และ ส่งผลต่อการคอมไพล์ไฟล์ต้นฉบับแต่ละไฟล์ โดยวางคอมไพเลอร์เกือบทั้งหมด ภายในไฟล์รายการด้วย
โปรดทราบว่าค่าอื่นที่ไม่ใช่ true
จะเปลี่ยนกลับเป็นลักษณะการทำงานเริ่มต้น คุณ
และยังสามารถกำหนด APP_SHORT_COMMANDS
ในไฟล์ Application.mk
เพื่อบังคับ
ลักษณะนี้ของโมดูลทั้งหมดในโปรเจ็กต์ของคุณ
เราไม่แนะนำให้เปิดใช้ฟีเจอร์นี้โดยค่าเริ่มต้นเนื่องจากจะทำให้บิลด์ ช้าลง
LOCAL_THIN_ARCHIVE
ตั้งค่าตัวแปรนี้เป็น true
เมื่อสร้างไลบรารีแบบคงที่ การดำเนินการนี้จะ
สร้างที่เก็บถาวรแบบ Thin ซึ่งเป็นไฟล์ไลบรารีที่ไม่มีไฟล์ออบเจ็กต์
แต่ให้ส่งเส้นทางไปยังออบเจ็กต์จริงที่ตามปกติ
มี
วิธีนี้มีประโยชน์ในการลดขนาดเอาต์พุตของบิลด์ ข้อเสียก็คือ ไลบรารีดังกล่าวไม่สามารถย้ายไปยังตำแหน่งอื่น (ทุกเส้นทางภายใน เป็นแบบสัมพัทธ์)
ค่าที่ถูกต้องคือ true
, false
หรือว่างเปล่า คุณสามารถกำหนดค่าเริ่มต้นได้ใน
Application.mk
ผ่านตัวแปร APP_THIN_ARCHIVE
LOCAL_FILTER_ASM
กำหนดตัวแปรนี้เป็นคำสั่ง Shell ที่ระบบบิลด์จะใช้เพื่อกรอง
ไฟล์การประกอบที่แยกหรือสร้างจากไฟล์ที่คุณระบุ
LOCAL_SRC_FILES
การกําหนดตัวแปรนี้ทําให้เกิดเหตุการณ์ต่อไปนี้
- ระบบบิลด์จะสร้างไฟล์การประกอบชั่วคราวจากซอร์ส C หรือ C++ ใดก็ได้ แทนการรวบรวมเป็นไฟล์ออบเจ็กต์
- ระบบบิลด์จะเรียกใช้คำสั่ง Shell ใน
LOCAL_FILTER_ASM
บนอุปกรณ์ใดก็ได้ ไฟล์การประกอบชั่วคราวและไฟล์การประกอบที่ระบุในLOCAL_SRC_FILES
ดังนั้นจึงสร้างไฟล์การประกอบชั่วคราวขึ้นมาอีกไฟล์หนึ่ง - ระบบบิลด์จะรวมไฟล์แอสเซมบ์ที่กรองแล้วเหล่านี้ลงในไฟล์ออบเจ็กต์
เช่น
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" ให้กับโปรแกรมประกอบ ตัวกรองต้องเป็นคำสั่ง Shell แบบสแตนด์อโลนที่ใช้ชื่อของอินพุต เป็นอาร์กิวเมนต์แรก และชื่อไฟล์เอาต์พุตเป็นอาร์กิวเมนต์ที่สอง เช่น
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
มาโครฟังก์ชันที่ NDK มีให้
ส่วนนี้อธิบายถึงมาโครฟังก์ชันของ GNU ที่ NDK มีให้ ใช้
$(call <function>)
เพื่อประเมินผล กลับมีข้อมูลที่เป็นข้อความ
ไดเรกทอรีของฉัน
มาโครนี้จะส่งคืนเส้นทางของ Makefile ที่รวมไว้ล่าสุด ซึ่งโดยทั่วไปจะเป็น
ไดเรกทอรีปัจจุบันของ Android.mk
my-dir
มีประโยชน์สำหรับคำจำกัดความ
LOCAL_PATH
ที่จุดเริ่มต้นของไฟล์ Android.mk
เช่น
LOCAL_PATH := $(call my-dir)
จากวิธีการทำงานของ GNU Make สิ่งที่มาโครนี้ส่งคืนจริงๆ คือเส้นทางของ
ไฟล์สร้างครั้งล่าสุดที่ระบบบิลด์รวมไว้เมื่อแยกวิเคราะห์สคริปต์บิลด์ สำหรับ
ด้วยเหตุนี้ คุณจึงไม่ควรเรียก my-dir
หลังจากรวมไฟล์อื่น
ตัวอย่างเช่น โปรดพิจารณาตัวอย่างต่อไปนี้
LOCAL_PATH := $(call my-dir)
# ... declare one module
include $(LOCAL_PATH)/foo/`Android.mk`
LOCAL_PATH := $(call my-dir)
# ... declare another module
ปัญหาก็คือการเรียกครั้งที่ 2 ไปยัง 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
ไฟล์ย่อยทั้งหมด
แสดงรายการไฟล์ Android.mk
ที่อยู่ในไดเรกทอรีย่อยทั้งหมดของ
เส้นทางmy-dir
ปัจจุบัน
คุณสามารถใช้ฟังก์ชันนี้เพื่อระบุลำดับชั้นของไดเรกทอรีต้นทางที่ซ้อนลึกสำหรับ
ระบบบิลด์ โดยค่าเริ่มต้น NDK จะค้นหาเฉพาะไฟล์ในไดเรกทอรีเท่านั้น
ที่มีไฟล์ Android.mk
อยู่
ไฟล์รูปแบบนี้
แสดงเส้นทางของไฟล์บิลด์ปัจจุบัน (ซึ่งระบบบิลด์ใช้ชื่อว่า )
ไฟล์หลัก
แสดงเส้นทางของไฟล์รูปแบบหลักในโครงสร้างการรวม (เส้นทางของ ไฟล์ที่มีไฟล์ปัจจุบัน)
ไฟล์แบ่งย่า/ตายาย
แสดงเส้นทางของไฟล์รูปแบบพื้นฐานในโครงสร้างการรวม (เส้นทางของ ไฟล์ Makefile ที่รวมไฟล์ปัจจุบันไว้)
โมดูลนำเข้า
ฟังก์ชันที่ช่วยให้คุณค้นหาและรวมไฟล์ Android.mk
ของโมดูลได้โดย
ชื่อของโมดูล ตัวอย่างทั่วไปมีดังนี้
$(call import-module,<name>)
ในตัวอย่างนี้ ระบบบิลด์จะมองหาโมดูลที่ติดแท็ก <name>
ใน
รายการไดเรกทอรีที่อ้างอิงว่าสภาพแวดล้อม NDK_MODULE_PATH
ของคุณ
และรวมไฟล์ Android.mk
ไว้ให้คุณโดยอัตโนมัติ