Android.mk

توضّح هذه الصفحة بنية ملف إصدار 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

ملاحظة: إذا كان اسم الوحدة يبدأ بالفعل بـ lib، فلن يبدأ نظام التصميم إلحاق بادئة lib إضافية وتأخذ اسم الوحدة كما هي، وتضيف الإضافة .so. إذًا، كان هناك ملف مصدر يسمى في الأصل، على سبيل المثال، libfoo.c ملف كائن مشترك يسمى libfoo.so. هذا السلوك هو المكتبات المتاحة التي تنشئها مصادر نظام Android الأساسي من Android.mk الملفات؛ تبدأ أسماء هذه المكتبات بـ lib.

يعدد السطر التالي الملفات المصدر، مع وجود مسافات تحدد الملفات المتعددة الملفات:

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)

ملاحظة: لا تتضمن معظم تطبيقات Android ملفات قابلة للتنفيذ، ولكنها مفيدة إنشاء اختبارات الوحدات وأدوات تصحيح الأخطاء الأخرى.

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) وبنية متوافقة.

الجدول 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

متغيّرات وصف الوحدة

تصف المتغيرات الواردة في هذا القسم الوحدة الخاصة بك بنظام الإصدار. على كل وصف الوحدة يجب أن يتبع هذا التدفق الأساسي:

1. قم بتهيئة أو إلغاء تحديد المتغيرات المرتبطة بالوحدة، باستخدام متغيّر "CLEAR_VARS"
2. عيّن قيمًا للمتغيرات المستخدمة لوصف الوحدة.
3. اضبط نظام تصميم 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 بشكل أكثر سهولة.

ملاحظة: يجب دائمًا استخدام الشرطة المائلة للأمام بنمط Unix (/) في ملفات الإصدار. التصميم نظام التشغيل لا يتعامل مع الشرطة المائلة للخلف بنمط Windows (\) بشكل صحيح.

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 هذا ، راجع واجهات برمجة التطبيقات الأصلية.

ملاحظة: في حال تحديد هذا المتغيّر لمكتبة ثابتة، يتجاهل نظام الإصدار. وتطبع "ndk-build" تحذيرًا.

LOCAL_LDFLAGS

تتضمّن هذه القائمة علامات الربط الأخرى التي يمكن لنظام التصميم استخدامها عند إنشاء مكتبة مشتركة أو ملف تنفيذي. على سبيل المثال، لاستخدام رابط ld.bfd على ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

ملاحظة: في حال تحديد هذا المتغيّر لمكتبة ثابتة، يتجاهل نظام الإصدار. وتطبع ndk تحذيرًا.

LOCAL_ALLOW_UNDEFINED_SYMBOLS

عندما يصادف نظام الإصدار مرجعًا غير محدد بشكل تلقائي أثناء محاولة إنشاء مشاركة، ستعرض الخطأ رمز غير معروف. هذا النمط في اكتشاف الأخطاء في التعليمات البرمجية المصدر.

لإيقاف عملية التحقّق هذه، عليك ضبط هذا المتغيّر على "true". لاحظ أن هذا الإعداد قد إلى تحميل المكتبة المشتركة في وقت التشغيل.

ملاحظة: في حال تحديد هذا المتغيّر لمكتبة ثابتة، يتجاهل نظام الإصدار. وتطبع ndk تحذيرًا.

الوضع المحلي

ينشئ نظام التصميم تلقائيًا برامج ثنائية مستهدفة من 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

ملاحظة: يمكنك أيضًا فرض إنشاء ثنائيات ARM على نظام التصميم من خلال ضبط APP_OPTIM في ملف Application.mk إلى debug. جارٍ تحديد debug تفرض إصدار ARM لأن برنامج تصحيح أخطاء سلسلة الأدوات لا يتعامل مع رمز Thumb. بشكل صحيح.

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 يؤدي تعريف هذا المتغير إلى حدوث الأشياء التالية:

1. يُنشئ نظام التصميم ملف تجميع مؤقت من أي مصدر C أو C++. بدلاً من تجميعها في ملف كائن.
2. ينفِّذ نظام الإصدار أمر Shell في LOCAL_FILTER_ASM على أي ملف تجميع مؤقت وعلى أي ملف تجميع مدرج في LOCAL_SRC_FILES، وبالتالي إنشاء ملف تجميع مؤقت آخر.
3. ويجمع نظام الإصدار ملفات التجميع هذه التي تمت فلترتها في ملف كائن.

مثلاً:

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 تلقائيًا بالنيابة عنك.