توضّح هذه الصفحة بنية ملف إصدار Android.mk
المُستخدَم من خلال
ndk-build
نظرة عامة
يتوفّر ملف Android.mk
في دليل فرعي من jni/
لمشروعك.
الدليل، ويصف المصادر والمكتبات المشتركة في نظام الإصدار.
إنه حقًا جزء صغير من ملف GNU يقوم بتحليله مرة واحدة أو
أخرى. يُعد ملف Android.mk
مفيدًا لتحديد الإعدادات على مستوى المشروع التي
يتبقى Application.mk
ونظام التصميم ومتغيرات البيئة.
غير محددة. ويمكنها أيضًا إلغاء الإعدادات على مستوى المشروع لوحدات معيّنة.
تسمح لك بنية Android.mk
بتجميع المصادر في وحدات.
الوحدة هي إما مكتبة ثابتة أو مكتبة مشتركة أو مكتبة مستقلة
ملف تنفيذي. يمكنك تحديد وحدة واحدة أو أكثر في كل ملف Android.mk
.
يمكنك استخدام ملف المصدر نفسه في وحدات متعددة. نظام التصميم فقط
تضع المكتبات المشتركة في حزمة التطبيق الخاصة بك. بالإضافة إلى ذلك،
يمكن للمكتبات إنشاء مكتبات مشتركة.
بالإضافة إلى مكتبات التغليف، يتعامل نظام التصميم مع مجموعة متنوعة من الأدوات
التفاصيل المخصصة لك. فعلى سبيل المثال، ليس عليك إدراج ملفات العنوان أو محتوى
الاعتمادية بين الملفات التي تم إنشاؤها في ملف Android.mk
إصدار NDK
بحساب هذه العلاقات تلقائيًا نيابة عنك. نتيجة لذلك،
ينبغي أن يكون قادرًا على الاستفادة من دعم سلسلة الأدوات/المنصة الجديدة في NDK مستقبلًا
الإصدارات بدون الحاجة إلى لمس ملف Android.mk
.
بنية هذا الملف قريبة جدًا من البنية المستخدَمة في ملفات Android.mk
.
سيتم توزيعها باستخدام المشروع المفتوح المصدر لنظام Android بالكامل. وفي حين أن نظام التصميم
طريقة التنفيذ التي تستخدمها، يكون التشابه بينهم
تهدف إلى تسهيل عملية إعادة استخدام مطوري التطبيقات
رمز المصدر للمكتبات الخارجية.
الأساسيات
قبل استكشاف بناء الجملة بالتفصيل، من المفيد البدء بفهم
أساسيات محتوى ملف 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
اسم الوحدة التي تريد
استخدم هذا المتغير مرة واحدة لكل وحدة في التطبيق.
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
ملف. بالإضافة إلى ذلك، مثال: نشاط أصلي
شرحًا تفصيليًا لملف 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)
BUILD_SHARED_LIBRARY
يشير هذا المتغير إلى نص برمجي للإنشاء يجمع كل المعلومات حول
الوحدة التي وفّرتها في متغيّرات 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
".
PREBUILT_SHARED_LIBRARY
يشير إلى نص برمجي للإصدار يُستخدَم لتحديد مكتبة مشتركة مصمّمة مسبقًا. إلغاء الإعجاب في
حالة BUILD_SHARED_LIBRARY
وBUILD_STATIC_LIBRARY
، تكون هنا قيمة
لا يمكن أن يكون LOCAL_SRC_FILES
ملف مصدر. بدلاً من ذلك، يجب أن يكون مسارًا واحدًا
مكتبة مشتركة تم إنشاؤها مسبقًا، مثل foo/libfoo.so
. بناء الجملة لاستخدام هذه
المتغير هو:
include $(PREBUILT_SHARED_LIBRARY)
يمكنك أيضًا الرجوع إلى مكتبة تم إنشاؤها مسبقًا في وحدة أخرى باستخدام
متغيّر "LOCAL_PREBUILTS
" لمزيد من المعلومات حول استخدام الإعدادات المسبقة الإنشاء، راجع
استخدام المكتبات المنشأة مسبقًا
PREBUILT_StatIC_LIBRARY
هذه السمة مماثلة لمكتبة PREBUILT_SHARED_LIBRARY
، ولكنّها في مكتبة ثابتة تم إنشاؤها مسبقًا. بالنسبة
للحصول على مزيد من المعلومات حول استخدام المباني المنشأة مسبقًا، راجع استخدام المكتبات المنشأة مسبقًا.
متغيّرات المعلومات المستهدفة
يحلّل نظام التصميم Android.mk
مرة واحدة لكل واجهة ABI تحدّدها APP_ABI
.
والذي يتم تحديده عادةً في ملف Application.mk
. إذا APP_ABI
هو all
، ثم يحلّل نظام التصميم Android.mk
مرة واحدة لكل ABI وNDK.
والدعم. يصف هذا القسم المتغيرات التي يحددها نظام الإصدار في كل مرة
وتحلّل Android.mk
.
TARGET_ARCH
مجموعة وحدة المعالجة المركزية التي يستهدفها نظام التصميم أثناء تحليله لجهاز Android.mk
هذا
الملف. سيكون هذا المتغيّر أحد ما يلي: arm
أو arm64
أو x86
أو x86_64
.
المنصة المستهدفة
رقم مستوى واجهة برمجة تطبيقات Android الذي يستهدفه نظام التصميم أثناء تحليل هذا
ملف Android.mk
. على سبيل المثال، تتوافق صور نظام Android 5.1 مع
المستوى 22 من واجهة برمجة تطبيقات Android: android-22
للحصول على قائمة كاملة بأسماء المنصات
صور نظام Android المقابلة، يمكنك الاطّلاع على واجهات برمجة التطبيقات الأصلية. تشير رسالة الأشكال البيانية
المثال التالي بناء الجملة لاستخدام هذا المتغير:
ifeq ($(TARGET_PLATFORM),android-22)
# ... do something ...
endif
TARGET_ARCH_ABI
واجهة التطبيق الثنائية (ABI) التي يستهدفها نظام التصميم أثناء تحليل ملف Android.mk
هذا.
يعرض الجدول 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 المستهدَفة الجديدة في المستقبل قيم مختلفة.
الهدف_المستهدف
سلسلة من مستوى واجهة برمجة تطبيقات Android وABI المستهدَفَين إنها مفيدة بشكل خاص عندما تريد الاختبار على صورة نظام مستهدفة محددة لجهاز حقيقي. على سبيل المثال، للتحقّق من توفّر جهاز ARM بسعة 64 بت يعمل بالمستوى 22 من واجهة برمجة تطبيقات Android:
ifeq ($(TARGET_ABI),android-22-arm64-v8a)
# ... do something ...
endif
متغيّرات وصف الوحدة
تصف المتغيرات الواردة في هذا القسم الوحدة الخاصة بك بنظام الإصدار. على كل وصف الوحدة يجب أن يتبع هذا التدفق الأساسي:
- قم بتهيئة أو إلغاء تحديد المتغيرات المرتبطة بالوحدة، باستخدام
متغيّر "
CLEAR_VARS
" - عيّن قيمًا للمتغيرات المستخدمة لوصف الوحدة.
- اضبط نظام تصميم NDK على استخدام نص الإنشاء المناسب للوحدة،
باستخدام المتغير
BUILD_XXX
.
المسار المحلي
يُستخدم هذا المتغير لتحديد مسار الملف الحالي. يجب تحديدها
في بداية ملف Android.mk
. يوضح المثال التالي كيفية القيام
لذلك:
LOCAL_PATH := $(call my-dir)
لا يؤدّي النص البرمجي الذي يشير إليه CLEAR_VARS
نقطة إلى محو هذا المتغيّر. ولذلك،
ما عليك سوى تحديده مرة واحدة، حتى إذا كان ملفك Android.mk
يصف وحدات متعددة.
الوحدة المحلية
يقوم هذا المتغير بتخزين اسم الوحدة الخاصة بك. يجب أن يكون فريدًا بين جميع الوحدات
أسماء، ويجب ألا يحتوي على أي مسافات. يجب عليك تحديدها قبل تضمين أي
النصوص البرمجية (بخلاف النص الخاص بـ CLEAR_VARS
). لا يجب إضافة أيّ من lib
أو امتداد الملف .so
أو .a
، فإن نظام التصميم يجعل هذه
التعديلات تلقائيًا. خلال Android.mk
وApplication.mk
يمكنك الرجوع إلى الوحدة من خلال اسمها غير المعدل. على سبيل المثال، ما يلي
سطر جديد لإنشاء وحدة مكتبة مشتركة تسمى 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_ملفّات
يحتوي هذا المتغير على قائمة بملفات المصدر التي يستخدمها نظام الإصدار
لإنشاء الوحدة. عدم إدراج سوى الملفات التي يجتازها نظام الإصدار
إلى المحول البرمجي، حيث إن نظام الإصدار يقوم تلقائيًا بحساب أي بيانات
والتبعيات لديك. يُرجى العلم أنّه يمكنك استخدام قيمة نسبية (بالنسبة إلى LOCAL_PATH
) وقيمة مطلقة.
مسارات الملفات.
نوصي بتجنب مسارات الملفات المطلقة؛ تؤدي المسارات النسبية إلى جعل Android.mk
بشكل أكثر سهولة.
LOCAL_CPP_امتداد
يمكنك استخدام هذا المتغير الاختياري للإشارة إلى امتداد ملف بخلاف
.cpp
لملفات مصدر C++. على سبيل المثال، يغيِّر السطر التالي دالة الرسم
الإضافة إلى .cxx
. (يجب أن يتضمّن الإعداد النقطة.)
LOCAL_CPP_EXTENSION := .cxx
ويمكنك استخدام هذا المتغيّر لتحديد إضافات متعدّدة. على سبيل المثال:
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
LOCAL_CPP_FEATURES
يمكنك استخدام هذا المتغير الاختياري للإشارة إلى أن التعليمات البرمجية تعتمد على بيانات محددة
ميزات C++. إنها تتيح علامات برنامج التجميع والرابط الصحيحة أثناء عملية الإنشاء
الدفع. بالنسبة إلى الملفات الثنائية التي تم إنشاؤها مسبقًا، يعلن هذا المتغير أيضًا عن الميزات
البرنامج الثنائي على هذا الأساس، مما يساعد على ضمان عمل الربط النهائي بشكل صحيح. أر
ننصحك باستخدام هذا المتغيّر بدلاً من تفعيل السمة -frtti
-fexceptions
في تعريف LOCAL_CPPFLAGS
مباشرةً.
يتيح استخدام هذا المتغير لنظام الإصدار استخدام العلامات المناسبة
لكل وحدة. استخدام LOCAL_CPPFLAGS
يجعل المحول البرمجي يستخدم كل ما هو محدد
لجميع الوحدات، بصرف النظر عن الحاجة الفعلية.
على سبيل المثال، للإشارة إلى استخدام الرمز البرمجي "RTTI" (معلومات نوع وقت التشغيل)، كتابة:
LOCAL_CPP_FEATURES := rtti
للإشارة إلى أن التعليمات البرمجية تستخدم استثناءات C++، اكتب:
LOCAL_CPP_FEATURES := exceptions
يمكنك أيضًا تحديد قيم متعددة لهذا المتغيّر. مثلاً:
LOCAL_CPP_FEATURES := rtti features
لا يهم الترتيب الذي تصف به القيم.
ما يلي:
يمكنك استخدام هذا المتغير الاختياري لتحديد قائمة من المسارات، بالنسبة إلى
دليل NDK root
، لإضافته إلى مسار بحث التضمين عند تجميع كل
المصادر (C وC++ وAssembly). مثلاً:
LOCAL_C_INCLUDES := sources/foo
أو حتى:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
حدد هذا المتغير قبل إعداد أي علامات تضمين مقابلة عبر
LOCAL_CFLAGS
أو LOCAL_CPPFLAGS
يستخدم نظام التصميم أيضًا مسارات LOCAL_C_INCLUDES
تلقائيًا عند إطلاقه.
تصحيح الأخطاء الأصلي باستخدام ndk-gdb.
المحلية
يحدد هذا المتغير الاختياري علامات المحول البرمجي لتمرير نظام الإصدار عند
إنشاء ملفات المصدر 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_SHARED_LIBRARIES
يمثّل هذا المتغيّر قائمة وحدات المكتبات المشتركة التي تظهر فيها هذه الوحدة. حسب وقت التشغيل تكون هذه المعلومات ضرورية في وقت الربط، ولتضمين المعلومات المقابلة في الملف الذي تم إنشاؤه.
المكتبات المحلية
هذا المتغيّر هو أحد متغيرات LOCAL_STATIC_LIBRARIES
، ويوضّح أن
أن يتعامل برنامج الربط مع وحدات المكتبة المرتبطة بها على أنّها أرشيفات كاملة. بالنسبة
لمزيد من المعلومات حول الأرشيفات بالكامل، يُرجى مراجعة مستندات GNU ld الخاصة بـ
علم --whole-archive
يكون هذا المتغير مفيدًا عندما تكون هناك تبعيات دائرية بين العديد من والمكتبات الثابتة. وعند استخدام هذا المتغير لإنشاء مكتبة مشتركة، إجبار نظام الإصدار على إضافة جميع ملفات الكائنات من مكتباتك الثابتة إلى ملف الثنائي النهائي. ولكن، الأمر نفسه لا ينطبق عند إنشاء ملفات تنفيذية.
المحلية
يحتوي هذا المتغير على قائمة علامات الربط الإضافية للاستخدام في إنشاء
المكتبة المشتركة أو الملف التنفيذي. وهي تتيح لك استخدام البادئة -l
لتمرير
باسم مكتبات النظام المحددة. على سبيل المثال، يخبر المثال التالي
أداة الربط لإنشاء وحدة ترتبط بـ /system/lib/libz.so
عند التحميل
الوقت:
LOCAL_LDLIBS := -lz
للاطّلاع على قائمة مكتبات النظام المكشوفة التي يمكنك الربط بها في NDK هذا ، راجع واجهات برمجة التطبيقات الأصلية.
LOCAL_LDFLAGS
تتضمّن هذه القائمة علامات الربط الأخرى التي يمكن لنظام التصميم استخدامها عند إنشاء
مكتبة مشتركة أو ملف تنفيذي. على سبيل المثال، لاستخدام رابط ld.bfd
على
ARM/X86:
LOCAL_LDFLAGS += -fuse-ld=bfd
LOCAL_ALLOW_UNDEFINED_SYMBOLS
عندما يصادف نظام الإصدار مرجعًا غير محدد بشكل تلقائي أثناء محاولة إنشاء مشاركة، ستعرض الخطأ رمز غير معروف. هذا النمط في اكتشاف الأخطاء في التعليمات البرمجية المصدر.
لإيقاف عملية التحقّق هذه، عليك ضبط هذا المتغيّر على "true
". لاحظ أن هذا الإعداد قد
إلى تحميل المكتبة المشتركة في وقت التشغيل.
الوضع المحلي
ينشئ نظام التصميم تلقائيًا برامج ثنائية مستهدفة من 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 في ملفات التجميع.
تجدر الإشارة إلى أنّ بعض وحدات المعالجة المركزية (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
في حال استخدام اللاحقتين، يجب أن تسبق السمة .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
. وهي تضيف أيضًا العلامات التي تم تصديرها إلى وحدة التخزين
LOCAL_CFLAGS
حتى تتمكّن من إلغائها بسهولة.
بالإضافة إلى ذلك، تكون العلاقة بين الوحدات متبادلة الفائدة: إذا كانت السمة zoo
تعتمد على
bar
، الذي يعتمد بدوره على foo
، ثم يكتسب zoo
أيضًا جميع العلامات
تم تصديره من foo
.
أخيرًا، لا يستخدم نظام التصميم العلامات المصدَّرة عند إنشاء الملفات على الجهاز
(أي بناء الوحدة التي يتم تصدير علاماتها). وبالتالي، في المثال
أعلاه، لا تمرر -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
، ولكن بالنسبة لعلامات الربط.
LOCAL_EXPORT_LDLIBS
يتشابه هذا المتغيّر مع LOCAL_EXPORT_CFLAGS
، حيث يخبر نظام الإصدار
أسماء مكتبات نظام معينة إلى المحول البرمجي. إضافة البادئة -l
إلى
لكل مكتبة تحددها.
لاحظ أن نظام التصميم يُلحق علامات الربط التي تم استيرادها إلى قيمة
المتغير 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)
في هذا المثال، يضع نظام التصميم -llog
في نهاية أمر الربط.
عند إنشاء libbar.so
. ويؤدي ذلك إلى إعلام القائم بالرابط بذلك، لأن libbar.so
تعتمد على foo
، وتعتمد أيضًا على مكتبة التسجيل الخاصة بالنظام.
الأوامر_المحلية
عليك ضبط هذا المتغيّر على true
عندما تحتوي الوحدة على عدد كبير جدًا من المصادر.
و/أو المكتبات الثابتة أو المشتركة التابعة. يؤدي القيام بذلك إلى إجبار نظام التصميم على
استخدام بنية @
للأرشيفات التي تحتوي على ملفات كائنات وسيطة أو روابط
المكتبات.
يمكن أن تكون هذه الميزة مفيدة في نظام التشغيل Windows، حيث يقبل سطر الأوامر الحد الأقصى من 8191 حرفًا فقط، والتي قد تكون صغيرة جدًا بالنسبة للمشروعات المعقدة. وكذلك تؤثر في تجميع ملفات المصدر الفردية، مما يؤدي إلى وضع جميع برامج التجميع علامات داخل ملفات القائمة أيضًا.
تجدر الإشارة إلى أنّ أي قيمة غير true
ستتم إعادتها إلى السلوك التلقائي. إِنْتَ
يمكن أيضًا تحديد APP_SHORT_COMMANDS
في ملف Application.mk
لفرض فرض
هذا السلوك لجميع الوحدات في مشروعك.
لا ننصح بتفعيل هذه الميزة تلقائيًا، لأنّها تجعل الإصدار أبطأ.
LOCAL_THIN_ARCHIVE
اضبط هذا المتغيّر على true
عند إنشاء مكتبات ثابتة. سيؤدي القيام بذلك إلى
إنشاء أرشيف رفيع أو ملف مكتبة لا يحتوي على ملفات الكائنات،
ولكن بدلاً من ذلك، قم فقط بتقديم المسارات إلى الكائنات الفعلية التي عادةً ما
تحتوي عليه.
ويُفيد ذلك في تقليل حجم نتائج الإصدار. العيب هو أن لا يمكن نقل هذه المكتبات إلى مكان مختلف (جميع المسارات داخلها نسبية).
القيم الصالحة هي 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 Make التي يوفرها 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
المشكلة هنا هي أن الاستدعاء الثاني لـ 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 الحالي (الذي من خلاله نظام الإصدار يسمى ).
ملف_إنشاء_عنصر رئيسي
لعرض مسار ملف makefile الأصلي في شجرة التضمين (مسار makefile الذي يتضمن الملف الحالي).
ملف-جراند-makefile
لعرض مسار ملف makefile الخاص بالجد في شجرة التضمين (مسار ملف makefile الذي يتضمن الملف الحالي).
وحدة الاستيراد
دالة تتيح لك العثور على ملف Android.mk
الخاص بالوحدة وتضمينه من خلال
اسم الوحدة. وفي ما يلي مثال نموذجي:
$(call import-module,<name>)
في هذا المثال، يبحث نظام التصميم عن الوحدة التي تم وضع علامة <name>
عليها في
قائمة الأدلة التي تشير إلى أنّ بيئة NDK_MODULE_PATH
مراجع للمتغيّرات، وتضمين ملف Android.mk
تلقائيًا بالنيابة عنك.