Android.mk

এই পৃষ্ঠাটি ndk-build দ্বারা ব্যবহৃত Android.mk বিল্ড ফাইলের সিনট্যাক্স বর্ণনা করে।

ওভারভিউ

Android.mk ফাইলটি আপনার প্রজেক্টের jni/ ডিরেক্টরির একটি সাবডিরেক্টরিতে থাকে এবং বিল্ড সিস্টেমে আপনার সোর্স এবং শেয়ার করা লাইব্রেরি বর্ণনা করে। এটি সত্যিই একটি ক্ষুদ্র GNU মেকফাইল খণ্ড যা বিল্ড সিস্টেম একবার বা একাধিকবার পার্স করে। Android.mk ফাইলটি প্রজেক্ট-ব্যাপী সেটিংস সংজ্ঞায়িত করার জন্য উপযোগী যা Application.mk , বিল্ড সিস্টেম এবং আপনার এনভায়রনমেন্ট ভেরিয়েবল অনির্ধারিত রেখে যায়। এটি নির্দিষ্ট মডিউলগুলির জন্য প্রকল্প-ব্যাপী সেটিংস ওভাররাইড করতে পারে।

Android.mk এর সিনট্যাক্স আপনাকে আপনার উত্সগুলিকে মডিউলগুলিতে গোষ্ঠীভুক্ত করতে দেয়৷ একটি মডিউল হয় একটি স্ট্যাটিক লাইব্রেরি, একটি শেয়ার্ড লাইব্রেরি, অথবা একটি স্বতন্ত্র এক্সিকিউটেবল। আপনি প্রতিটি Android.mk ফাইলে এক বা একাধিক মডিউল সংজ্ঞায়িত করতে পারেন এবং আপনি একাধিক মডিউলে একই সোর্স ফাইল ব্যবহার করতে পারেন। বিল্ড সিস্টেম শুধুমাত্র আপনার অ্যাপ্লিকেশন প্যাকেজে ভাগ করা লাইব্রেরি রাখে। উপরন্তু, স্ট্যাটিক লাইব্রেরি শেয়ার করা লাইব্রেরি তৈরি করতে পারে।

প্যাকেজিং লাইব্রেরি ছাড়াও, বিল্ড সিস্টেম আপনার জন্য বিভিন্ন অন্যান্য বিবরণ পরিচালনা করে। উদাহরণস্বরূপ, আপনার Android.mk ফাইলে জেনারেট করা ফাইলগুলির মধ্যে হেডার ফাইল বা স্পষ্ট নির্ভরতা তালিকাভুক্ত করার প্রয়োজন নেই৷ NDK বিল্ড সিস্টেম আপনার জন্য স্বয়ংক্রিয়ভাবে এই সম্পর্কগুলি গণনা করে। ফলস্বরূপ, আপনি আপনার Android.mk ফাইল স্পর্শ না করেই ভবিষ্যতে NDK রিলিজে নতুন টুলচেন/প্ল্যাটফর্ম সমর্থন থেকে উপকৃত হতে পারবেন।

এই ফাইলটির সিনট্যাক্স সম্পূর্ণ অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টের সাথে বিতরণ করা Android.mk ফাইলে ব্যবহৃত ফাইলের খুব কাছাকাছি। যদিও এগুলি ব্যবহার করে এমন বিল্ড সিস্টেম বাস্তবায়ন ভিন্ন, তবে তাদের মিল হল একটি ইচ্ছাকৃত ডিজাইনের সিদ্ধান্ত যার লক্ষ্য হল অ্যাপ্লিকেশন ডেভেলপারদের জন্য বহিরাগত লাইব্রেরির জন্য সোর্স কোড পুনরায় ব্যবহার করা সহজ করে তোলা।

বেসিক

সিনট্যাক্সটি বিশদভাবে অন্বেষণ করার আগে, একটি Android.mk ফাইলে কী রয়েছে তার মূল বিষয়গুলি বোঝার মাধ্যমে শুরু করা কার্যকর। এই অংশটি Hello-JNI নমুনায় Android.mk ফাইলটি ব্যবহার করে, ফাইলের প্রতিটি লাইন যে ভূমিকা পালন করে তা ব্যাখ্যা করে।

একটি Android.mk ফাইল অবশ্যই LOCAL_PATH ভেরিয়েবল সংজ্ঞায়িত করে শুরু করতে হবে:

LOCAL_PATH := $(call my-dir)

এই ভেরিয়েবলটি ডেভেলপমেন্ট ট্রিতে সোর্স ফাইলের অবস্থান নির্দেশ করে। এখানে, বিল্ড সিস্টেম দ্বারা প্রদত্ত ম্যাক্রো ফাংশন my-dir , বর্তমান ডিরেক্টরির পাথ ফেরত দেয় (যে ডিরেক্টরিটি Android.mk ফাইলটিই থাকে)।

পরবর্তী লাইন CLEAR_VARS ভেরিয়েবল ঘোষণা করে, যার মান বিল্ড সিস্টেম প্রদান করে।

include $(CLEAR_VARS)

CLEAR_VARS ভেরিয়েবল একটি বিশেষ GNU মেকফাইলের দিকে নির্দেশ করে যা আপনার জন্য অনেক 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 ফাইলকে কয়েকবার পার্স করতে পারে, প্রতিবার এই ভেরিয়েবলগুলির জন্য একটি ভিন্ন সংজ্ঞা ব্যবহার করে।

CLEAR_VARS

এই ভেরিয়েবলটি একটি বিল্ড স্ক্রিপ্টের দিকে নির্দেশ করে যা নীচের "ডেভেলপার-সংজ্ঞায়িত ভেরিয়েবল" বিভাগে তালিকাভুক্ত প্রায় সমস্ত LOCAL_XXX ভেরিয়েবলকে অসংজ্ঞায়িত করে৷ একটি নতুন মডিউল বর্ণনা করার আগে এই স্ক্রিপ্টটি অন্তর্ভুক্ত করতে এই ভেরিয়েবলটি ব্যবহার করুন। এটি ব্যবহারের জন্য সিনট্যাক্স হল:

include $(CLEAR_VARS)

BUILD_EXECUTABLE

এই ভেরিয়েবলটি একটি বিল্ড স্ক্রিপ্টের দিকে নির্দেশ করে যা আপনার 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_STATIC_LIBRARY

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 এর মতো, কিন্তু একটি পূর্বনির্মাণ স্ট্যাটিক লাইব্রেরির জন্য। প্রিবিল্ট ব্যবহার সম্পর্কে আরও তথ্যের জন্য, প্রিবিল্ট লাইব্রেরি ব্যবহার করুন দেখুন।

লক্ষ্য তথ্য ভেরিয়েবল

বিল্ড সিস্টেম APP_ABI ভেরিয়েবল দ্বারা নির্দিষ্ট করা ABI প্রতি একবার Android.mk পার্স করে, যা সাধারণত আপনার Application.mk ফাইলে সংজ্ঞায়িত করা হয়। যদি APP_ABI all হয়, তাহলে বিল্ড সিস্টেমটি NDK সমর্থন করে ABI প্রতি একবার Android.mk পার্স করে। এই বিভাগটি Android.mk পার্স করার সময় বিল্ড সিস্টেমটি সংজ্ঞায়িত করে এমন ভেরিয়েবল বর্ণনা করে।

TARGET_ARCH

এই Android.mk ফাইলটি পার্স করার সময় বিল্ড সিস্টেমটি লক্ষ্য করছে CPU পরিবার। এই ভেরিয়েবলের একটি হবে: arm , arm64 , x86 , or x86_64 ।

TARGET_PLATFORM

এই Android.mk ফাইলটি পার্স করার সময় বিল্ড সিস্টেমটি লক্ষ্য করছে Android API স্তরের নম্বর। উদাহরণস্বরূপ, অ্যান্ড্রয়েড 5.1 সিস্টেমের চিত্রগুলি অ্যান্ড্রয়েড API স্তর 22: android-22 এর সাথে মিলে যায়। প্ল্যাটফর্মের নাম এবং সংশ্লিষ্ট অ্যান্ড্রয়েড সিস্টেম চিত্রগুলির একটি সম্পূর্ণ তালিকার জন্য, নেটিভ API দেখুন। নিম্নলিখিত উদাহরণ এই ভেরিয়েবল ব্যবহার করার জন্য সিনট্যাক্স দেখায়: 

ifeq ($(TARGET_PLATFORM),android-22)
    # ... do something ...
endif

TARGET_ARCH_ABI

এবিআই বিল্ড সিস্টেমটি লক্ষ্য করছে কারণ এটি এই Android.mk ফাইলটি পার্স করে। সারণি 1 প্রতিটি সমর্থিত CPU এবং আর্কিটেকচারের জন্য ব্যবহৃত ABI সেটিং দেখায়।

সারণি 1. বিভিন্ন CPU এবং আর্কিটেকচারের জন্য ABI সেটিংস।

সিপিইউ এবং আর্কিটেকচার সেটিং
ARMv7 armeabi-v7a
ARMv8 AArch64 arm64-v8a
i686 x86
x86-64 x86_64

নিম্নলিখিত উদাহরণ দেখায় কিভাবে লক্ষ্য CPU-এবং-ABI সমন্বয় হিসাবে ARMv8 AArch64 চেক করতে হয়: 

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

আর্কিটেকচার ABIs এবং সংশ্লিষ্ট সামঞ্জস্যের সমস্যা সম্পর্কে আরো বিস্তারিত জানার জন্য, Android ABIs দেখুন।

ভবিষ্যতে নতুন লক্ষ্য ABI-এর বিভিন্ন মান থাকবে।

TARGET_ABI

টার্গেট অ্যান্ড্রয়েড এপিআই লেভেল এবং এবিআই-এর সংমিশ্রণ। এটি বিশেষভাবে দরকারী যখন আপনি একটি বাস্তব ডিভাইসের জন্য একটি নির্দিষ্ট লক্ষ্য সিস্টেম চিত্রের বিরুদ্ধে পরীক্ষা করতে চান। উদাহরণস্বরূপ, Android API স্তর 22 এ চলমান একটি 64-বিট ARM ডিভাইস পরীক্ষা করতে: 

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
  # ... do something ...
endif

মডিউল-বর্ণনা ভেরিয়েবল

এই বিভাগের ভেরিয়েবলগুলি বিল্ড সিস্টেমে আপনার মডিউল বর্ণনা করে। প্রতিটি মডিউল বিবরণ এই মৌলিক প্রবাহ অনুসরণ করা উচিত:

  1. CLEAR_VARS ভেরিয়েবল ব্যবহার করে মডিউলের সাথে যুক্ত ভেরিয়েবল শুরু বা অসংজ্ঞায়িত করুন।
  2. মডিউল বর্ণনা করতে ব্যবহৃত ভেরিয়েবলের মান বরাদ্দ করুন।
  3. BUILD_XXX ভেরিয়েবল ব্যবহার করে মডিউলের জন্য উপযুক্ত বিল্ড স্ক্রিপ্ট ব্যবহার করতে NDK বিল্ড সিস্টেম সেট করুন।

LOCAL_PATH

এই ভেরিয়েবলটি বর্তমান ফাইলের পাথ দিতে ব্যবহৃত হয়। আপনার Android.mk ফাইলের শুরুতে আপনাকে অবশ্যই এটি সংজ্ঞায়িত করতে হবে। নিম্নলিখিত উদাহরণ দেখায় কিভাবে এটি করতে হয়: 

LOCAL_PATH := $(call my-dir)

যে স্ক্রিপ্টে CLEAR_VARS পয়েন্ট এই ভেরিয়েবলটি পরিষ্কার করে না। অতএব, আপনার Android.mk ফাইল একাধিক মডিউল বর্ণনা করলেও, আপনাকে শুধুমাত্র একবার এটি সংজ্ঞায়িত করতে হবে।

LOCAL_MODULE

এই ভেরিয়েবলটি আপনার মডিউলের নাম সংরক্ষণ করে। এটি সমস্ত মডিউল নামের মধ্যে অনন্য হতে হবে, এবং কোনো স্পেস থাকা উচিত নয়। যেকোনো স্ক্রিপ্ট ( 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_FILES

এই ভেরিয়েবলটিতে সোর্স ফাইলের তালিকা রয়েছে যা বিল্ড সিস্টেম মডিউল তৈরি করতে ব্যবহার করে। বিল্ড সিস্টেম প্রকৃতপক্ষে কম্পাইলারের কাছে যে ফাইলগুলি পাস করে তা কেবলমাত্র তালিকাভুক্ত করুন, যেহেতু বিল্ড সিস্টেম স্বয়ংক্রিয়ভাবে কোনও সম্পর্কিত নির্ভরতা গণনা করে। মনে রাখবেন আপনি আপেক্ষিক ( LOCAL_PATH ) এবং পরম ফাইল পাথ উভয়ই ব্যবহার করতে পারেন।

আমরা পরম ফাইল পাথ এড়ানোর পরামর্শ দিই; আপেক্ষিক পাথ আপনার Android.mk ফাইলকে আরো বহনযোগ্য করে তোলে।

LOCAL_CPP_EXTENSION

আপনি আপনার C++ সোর্স ফাইলের জন্য .cpp ছাড়া অন্য কোনো ফাইল এক্সটেনশন নির্দেশ করতে এই ঐচ্ছিক ভেরিয়েবলটি ব্যবহার করতে পারেন। উদাহরণস্বরূপ, নিম্নলিখিত লাইনটি এক্সটেনশনকে .cxx এ পরিবর্তন করে। (সেটিংয়ে অবশ্যই ডট থাকতে হবে।) 

LOCAL_CPP_EXTENSION := .cxx

আপনি একাধিক এক্সটেনশন নির্দিষ্ট করতে এই ভেরিয়েবল ব্যবহার করতে পারেন। উদাহরণস্বরূপ: 

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

আপনার কোড নির্দিষ্ট C++ বৈশিষ্ট্যের উপর নির্ভর করে তা নির্দেশ করতে আপনি এই ঐচ্ছিক পরিবর্তনশীল ব্যবহার করতে পারেন। এটি বিল্ড প্রক্রিয়া চলাকালীন সঠিক কম্পাইলার এবং লিঙ্কার পতাকা সক্ষম করে। প্রি-বিল্ট বাইনারিগুলির জন্য, এই ভেরিয়েবলটি ঘোষণা করে যে বাইনারি কোন বৈশিষ্ট্যগুলির উপর নির্ভর করে, এইভাবে চূড়ান্ত লিঙ্কিং সঠিকভাবে কাজ করে তা নিশ্চিত করতে সহায়তা করে। আমরা সুপারিশ করি যে আপনি সরাসরি আপনার LOCAL_CPPFLAGS সংজ্ঞায় -frtti এবং -fexceptions সক্রিয় করার পরিবর্তে এই পরিবর্তনশীলটি ব্যবহার করুন৷

এই ভেরিয়েবল ব্যবহার করে বিল্ড সিস্টেমকে প্রতিটি মডিউলের জন্য উপযুক্ত পতাকা ব্যবহার করার অনুমতি দেয়। 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++ এবং সমাবেশ) কম্পাইল করার সময় অন্তর্ভুক্ত অনুসন্ধান পাথ যোগ করতে। যেমন: 

LOCAL_C_INCLUDES := sources/foo

অথবা এমনকি: 

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo

LOCAL_CFLAGS বা LOCAL_CPPFLAGS এর মাধ্যমে কোনো সংশ্লিষ্ট অন্তর্ভুক্তি পতাকা সেট করার আগে এই ভেরিয়েবলটিকে সংজ্ঞায়িত করুন।

ndk-gdb এর সাথে নেটিভ ডিবাগিং চালু করার সময় বিল্ড সিস্টেম স্বয়ংক্রিয়ভাবে LOCAL_C_INCLUDES পাথ ব্যবহার করে।

LOCAL_ASFLAGS

.s বা .S ফাইল তৈরি করার সময় ফ্ল্যাগগুলিকে ক্ল্যাং-এ পাস করা হবে৷

LOCAL_ASMFLAGS

.asm ফাইল তৈরি করার সময় পতাকা যা yasm-এ পাঠানো হবে।

LOCAL_CFLAGS

ফ্ল্যাগ যা C, C++, এবং কিছু সমাবেশ ( .s এবং .S , কিন্তু .asm নয়) সোর্স ফাইল তৈরি করার সময় ক্ল্যাং-এ পাস করা হবে। এটি করার ক্ষমতা অতিরিক্ত ম্যাক্রো সংজ্ঞা বা কম্পাইল বিকল্পগুলি নির্দিষ্ট করার জন্য দরকারী হতে পারে। শুধুমাত্র C++ এর জন্য পতাকা নির্দিষ্ট করতে LOCAL_CPPFLAGS ব্যবহার করুন। শুধুমাত্র C এর জন্য পতাকা নির্দিষ্ট করতে LOCAL_CONLYFLAGS ব্যবহার করুন।

আপনার Android.mk ফাইলে অপ্টিমাইজেশান/ডিবাগিং লেভেল পরিবর্তন না করার চেষ্টা করুন। Application.mk ফাইলে প্রাসঙ্গিক তথ্য ব্যবহার করে বিল্ড সিস্টেম আপনার জন্য স্বয়ংক্রিয়ভাবে এই সেটিংটি পরিচালনা করতে পারে। এটি এইভাবে করা বিল্ড সিস্টেমকে ডিবাগিংয়ের সময় ব্যবহৃত দরকারী ডেটা ফাইল তৈরি করতে দেয়।

লেখার মাধ্যমে অতিরিক্ত অন্তর্ভুক্ত পাথগুলি নির্দিষ্ট করা সম্ভব: 

LOCAL_CFLAGS += -I<path>,

যাইহোক, এই উদ্দেশ্যে LOCAL_C_INCLUDES ব্যবহার করা ভাল, যেহেতু এটি করার ফলে ndk-gdb-এর সাথে নেটিভ ডিবাগিংয়ের জন্য উপলব্ধ পাথগুলিও ব্যবহার করা সম্ভব হয়।

LOCAL_CONLYFLAGS

C উত্স কম্পাইল করার সময় ফ্ল্যাগগুলি ক্ল্যাং-এ পাস করা হবে। LOCAL_CFLAGS এর বিপরীতে, C++ বা সমাবেশের উত্স কম্পাইল করার সময় LOCAL_CONLYFLAGS ক্ল্যাং-এ পাস করা হবে না।

LOCAL_CPPFLAGS

কম্পাইলার ফ্ল্যাগের একটি ঐচ্ছিক সেট যা শুধুমাত্র C++ সোর্স ফাইল তৈরি করার সময় পাস করা হবে। তারা কম্পাইলারের কমান্ড লাইনে LOCAL_CFLAGS পরে উপস্থিত হবে। C এবং C++ উভয়ের জন্য পতাকা নির্দিষ্ট করতে LOCAL_CFLAGS ব্যবহার করুন।

LOCAL_STATIC_LIBRARIS

এই ভেরিয়েবলটি স্ট্যাটিক লাইব্রেরি মডিউলগুলির তালিকা সংরক্ষণ করে যার উপর বর্তমান মডিউল নির্ভর করে।

যদি বর্তমান মডিউলটি একটি শেয়ার্ড লাইব্রেরি বা এক্সিকিউটেবল হয়, তাহলে এই ভেরিয়েবলটি এই লাইব্রেরিগুলিকে ফলস্বরূপ বাইনারিতে লিঙ্ক করতে বাধ্য করবে।

যদি বর্তমান মডিউলটি একটি স্ট্যাটিক লাইব্রেরি হয়, তবে এই ভেরিয়েবলটি সহজভাবে নির্দেশ করে যে বর্তমানের উপর নির্ভর করে অন্যান্য মডিউলগুলিও তালিকাভুক্ত লাইব্রেরির উপর নির্ভর করবে।

LOCAL_SHARED_LIBRARIS

এই ভেরিয়েবলটি শেয়ার্ড লাইব্রেরি মডিউলের তালিকা যার উপর এই মডিউল রানটাইম নির্ভর করে। এই তথ্যটি লিঙ্কের সময় প্রয়োজনীয়, এবং উত্পন্ন ফাইলে সংশ্লিষ্ট তথ্য এমবেড করার জন্য।

LOCAL_WHOLE_STATIC_LIBRARIS

এই ভেরিয়েবলটি LOCAL_STATIC_LIBRARIES এর একটি বৈকল্পিক, এবং এটি প্রকাশ করে যে লিঙ্কারের সংশ্লিষ্ট লাইব্রেরি মডিউলগুলিকে সম্পূর্ণ আর্কাইভ হিসাবে বিবেচনা করা উচিত। সম্পূর্ণ আর্কাইভ সম্পর্কে আরও তথ্যের জন্য, --whole-archive পতাকার জন্য GNU ld ডকুমেন্টেশন দেখুন।

যখন বেশ কয়েকটি স্ট্যাটিক লাইব্রেরির মধ্যে বৃত্তাকার নির্ভরতা থাকে তখন এই পরিবর্তনশীলটি কার্যকর। আপনি যখন একটি ভাগ করা লাইব্রেরি তৈরি করতে এই ভেরিয়েবলটি ব্যবহার করেন, তখন এটি বিল্ড সিস্টেমকে আপনার স্ট্যাটিক লাইব্রেরি থেকে চূড়ান্ত বাইনারিতে সমস্ত অবজেক্ট ফাইল যুক্ত করতে বাধ্য করবে। এক্সিকিউটেবল তৈরি করার সময় একই কথা সত্য নয়।

LOCAL_LDLIBS

এই ভেরিয়েবলে আপনার শেয়ার করা লাইব্রেরি বা এক্সিকিউটেবল তৈরিতে ব্যবহারের জন্য অতিরিক্ত লিঙ্কার পতাকার তালিকা রয়েছে। এটি আপনাকে নির্দিষ্ট সিস্টেম লাইব্রেরির নাম পাস করতে -l উপসর্গ ব্যবহার করতে সক্ষম করে। উদাহরণস্বরূপ, নিম্নলিখিত উদাহরণ লিঙ্কারকে একটি মডিউল তৈরি করতে বলে যা লোডের সময় /system/lib/libz.so এর সাথে লিঙ্ক করে: 

LOCAL_LDLIBS := -lz

উন্মুক্ত সিস্টেম লাইব্রেরির তালিকার জন্য যার সাথে আপনি এই NDK রিলিজে লিঙ্ক করতে পারেন, নেটিভ API দেখুন।

LOCAL_LDFLAGS

আপনার শেয়ার্ড লাইব্রেরি বা এক্সিকিউটেবল তৈরি করার সময় ব্যবহার করার জন্য বিল্ড সিস্টেমের জন্য অন্যান্য লিঙ্কার পতাকার তালিকা। উদাহরণস্বরূপ, ARM/X86 এ ld.bfd লিঙ্কার ব্যবহার করতে: 

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

ডিফল্টরূপে, যখন বিল্ড সিস্টেম একটি অনির্ধারিত রেফারেন্সের মুখোমুখি হয় যা একটি শেয়ার্ড তৈরি করার চেষ্টা করার সময় সম্মুখীন হয়, এটি একটি অনির্ধারিত প্রতীক ত্রুটি নিক্ষেপ করবে। এই ত্রুটি আপনাকে আপনার সোর্স কোডে বাগ ধরতে সাহায্য করতে পারে।

এই চেকটি নিষ্ক্রিয় করতে, এই ভেরিয়েবলটিকে true সেট করুন। মনে রাখবেন যে এই সেটিংটি রানটাইমে শেয়ার করা লাইব্রেরি লোড হতে পারে।

LOCAL_ARM_MODE

ডিফল্টরূপে, বিল্ড সিস্টেম থাম্ব মোডে ARM টার্গেট বাইনারি তৈরি করে, যেখানে প্রতিটি নির্দেশ 16 বিট চওড়া এবং thumb/ ডিরেক্টরিতে STL লাইব্রেরির সাথে লিঙ্ক করা হয়। এই পরিবর্তনশীলটিকে arm হিসাবে সংজ্ঞায়িত করা বিল্ড সিস্টেমকে 32-বিট arm মোডে মডিউলের অবজেক্ট ফাইল তৈরি করতে বাধ্য করে। নিম্নলিখিত উদাহরণ দেখায় কিভাবে এটি করতে হয়: 

LOCAL_ARM_MODE := arm

আপনি উৎস ফাইলের নামগুলিতে .arm প্রত্যয় যুক্ত করে শুধুমাত্র arm মোডে নির্দিষ্ট উত্স তৈরি করতে বিল্ড সিস্টেমকে নির্দেশ দিতে পারেন। উদাহরণস্বরূপ, নিম্নলিখিত উদাহরণটি বিল্ড সিস্টেমকে সবসময় এআরএম মোডে bar.c কম্পাইল করতে বলে, কিন্তু LOCAL_ARM_MODE এর মান অনুযায়ী foo.c তৈরি করতে বলে। 

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

আপনি যখন armeabi-v7a ABI লক্ষ্য করছেন তখনই এই পরিবর্তনশীলটি গুরুত্বপূর্ণ। এটি আপনার C এবং C++ উত্সগুলিতে ARM Advanced SIMD (NEON) কম্পাইলার অন্তর্নিহিত ব্যবহারের অনুমতি দেয়, সেইসাথে অ্যাসেম্বলি ফাইলগুলিতে NEON নির্দেশাবলী।

মনে রাখবেন যে সমস্ত ARMv7-ভিত্তিক CPU গুলি NEON নির্দেশ সেট এক্সটেনশন সমর্থন করে না। এই কারণে, রানটাইমে এই কোডটি নিরাপদে ব্যবহার করতে আপনাকে অবশ্যই রানটাইম সনাক্তকরণ করতে হবে। আরও তথ্যের জন্য, নিয়ন সমর্থন এবং CPU বৈশিষ্ট্য দেখুন।

বিকল্পভাবে, আপনি নির্দিষ্ট করতে .neon প্রত্যয় ব্যবহার করতে পারেন যে বিল্ড সিস্টেম শুধুমাত্র NEON সমর্থন সহ নির্দিষ্ট উত্স ফাইলগুলি কম্পাইল করে। নিম্নলিখিত উদাহরণে, বিল্ড সিস্টেমটি থাম্ব এবং নিয়ন সমর্থন সহ foo.c , থাম্ব সমর্থন সহ bar.c এবং ARM এবং NEON-এর সমর্থন সহ zoo.c সংকলন করে: 

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

যদি আপনি উভয় প্রত্যয় ব্যবহার করেন, তাহলে .arm এর আগে .neon লিখতে হবে।

LOCAL_DISABLE_FORMAT_STRING_CHECKS

ডিফল্টরূপে, বিল্ড সিস্টেম ফর্ম্যাট স্ট্রিং সুরক্ষা সহ কোড কম্পাইল করে। যদি একটি অ-স্থির বিন্যাস স্ট্রিং একটি printf স্টাইল ফাংশনে ব্যবহার করা হয় তাহলে এটি একটি কম্পাইলার ত্রুটিকে বাধ্য করে। এই সুরক্ষাটি ডিফল্টরূপে চালু থাকে, তবে আপনি এই ভেরিয়েবলের মান true এ সেট করে এটি নিষ্ক্রিয় করতে পারেন। আমরা একটি বাধ্যতামূলক কারণ ছাড়া এটি করার সুপারিশ না.

LOCAL_EXPORT_CFLAGS

LOCAL_STATIC_LIBRARIES বা LOCAL_SHARED_LIBRARIES ভেরিয়েবলের মাধ্যমে এটি ব্যবহার করে এমন অন্য কোনো মডিউলের LOCAL_CFLAGS সংজ্ঞাতে যোগ করতে এই ভেরিয়েবলটি C/C++ কম্পাইলার ফ্ল্যাগের একটি সেট রেকর্ড করে।

উদাহরণস্বরূপ, নিম্নলিখিত মডিউলগুলির জোড়া বিবেচনা করুন: 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)

এখানে, bar.c তৈরি করার সময় বিল্ড সিস্টেম কম্পাইলারকে -DFOO=1 এবং -DBAR=2 ফ্ল্যাগগুলি পাস করে। এটি আপনার মডিউলের LOCAL_CFLAGS এ রপ্তানি করা পতাকাগুলিকেও প্রিপেন্ড করে যাতে আপনি সহজেই সেগুলিকে ওভাররাইড করতে পারেন৷

উপরন্তু, মডিউলগুলির মধ্যে সম্পর্ক ট্রানজিটিভ: যদি zoo bar উপর নির্ভর করে, যা ফলস্বরূপ foo উপর নির্ভর করে, তাহলে zoo ও foo থেকে রপ্তানি করা সমস্ত পতাকা উত্তরাধিকার সূত্রে পায়।

অবশেষে, স্থানীয়ভাবে নির্মাণ করার সময় বিল্ড সিস্টেম রপ্তানিকৃত পতাকা ব্যবহার করে না (অর্থাৎ, মডিউলটি যার পতাকা রপ্তানি করছে)। সুতরাং, উপরের উদাহরণে, foo/foo.c তৈরি করার সময় এটি কম্পাইলারের কাছে -DFOO=1 পাস করে না। স্থানীয়ভাবে নির্মাণ করতে, পরিবর্তে 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 ভেরিয়েবলের মানের সাথে আমদানি করা লিঙ্কার পতাকা যুক্ত করে। এটি ইউনিক্স লিঙ্কারদের কাজ করার কারণে এটি করে।

এই ভেরিয়েবলটি সাধারণত কার্যকর হয় যখন মডিউল 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)

এই উদাহরণে, বিল্ড সিস্টেম libbar.so তৈরি করার সময় লিঙ্কার কমান্ডের শেষে -llog রাখে। এটি করা লিঙ্কারকে বলে যে, libbar.so foo উপর নির্ভর করে, এটি সিস্টেম লগিং লাইব্রেরির উপরও নির্ভর করে।

LOCAL_SHORT_COMMANDS

যখন আপনার মডিউলে অনেক বেশি সংখ্যক উৎস এবং/অথবা নির্ভরশীল স্ট্যাটিক বা ভাগ করা লাইব্রেরি থাকে তখন এই ভেরিয়েবলটিকে true হিসাবে সেট করুন। এটি করা বিল্ড সিস্টেমকে মধ্যবর্তী অবজেক্ট ফাইল বা লিঙ্কিং লাইব্রেরি ধারণকারী আর্কাইভের জন্য @ সিনট্যাক্স ব্যবহার করতে বাধ্য করে।

এই বৈশিষ্ট্যটি উইন্ডোজে কার্যকর হতে পারে, যেখানে কমান্ড লাইন সর্বাধিক 8191 অক্ষর গ্রহণ করে, যা জটিল প্রকল্পগুলির জন্য খুব ছোট হতে পারে। এটি পৃথক উত্স ফাইলগুলির সংকলনকেও প্রভাবিত করে, তালিকা ফাইলগুলির মধ্যে প্রায় সমস্ত কম্পাইলার ফ্ল্যাগ স্থাপন করে।

মনে রাখবেন true ছাড়া অন্য কোনো মান ডিফল্ট আচরণে ফিরে যাবে। আপনি আপনার Application.mk ফাইলে APP_SHORT_COMMANDS সংজ্ঞায়িত করতে পারেন যাতে আপনার প্রজেক্টের সমস্ত মডিউলের জন্য এই আচরণটি বাধ্য করা যায়।

আমরা ডিফল্টরূপে এই বৈশিষ্ট্যটি সক্ষম করার পরামর্শ দিই না, কারণ এটি নির্মাণকে ধীর করে তোলে।

LOCAL_THIN_ARCHIVE

স্ট্যাটিক লাইব্রেরি তৈরি করার সময় এই ভেরিয়েবলটিকে true হিসাবে সেট করুন। এটি করার ফলে একটি পাতলা আর্কাইভ তৈরি হবে, একটি লাইব্রেরি ফাইল যা বস্তু ফাইল ধারণ করে না, কিন্তু পরিবর্তে শুধুমাত্র প্রকৃত বস্তুর পাথ ফাইল করে যা এটি সাধারণত ধারণ করে।

এটি আপনার বিল্ড আউটপুটের আকার কমাতে কার্যকর। অসুবিধা হল যে এই ধরনের লাইব্রেরিগুলিকে অন্য জায়গায় সরানো যায় না (এগুলির ভিতরের সমস্ত পথ আপেক্ষিক)।

বৈধ মান true , false বা খালি। APP_THIN_ARCHIVE ভেরিয়েবলের মাধ্যমে আপনার Application.mk ফাইলে একটি ডিফল্ট মান সেট করা যেতে পারে।

LOCAL_FILTER_ASM

এই ভেরিয়েবলটিকে একটি শেল কমান্ড হিসাবে সংজ্ঞায়িত করুন যা বিল্ড সিস্টেম আপনার LOCAL_SRC_FILES এর জন্য নির্দিষ্ট করা ফাইলগুলি থেকে নিষ্কাশিত বা জেনারেট করা অ্যাসেম্বলি ফাইলগুলিকে ফিল্টার করতে ব্যবহার করবে। এই পরিবর্তনশীল সংজ্ঞায়িত করার ফলে নিম্নলিখিত জিনিসগুলি ঘটতে পারে:

  1. বিল্ড সিস্টেম একটি অবজেক্ট ফাইলে কম্পাইল করার পরিবর্তে যেকোনো C বা C++ সোর্স ফাইল থেকে একটি অস্থায়ী সমাবেশ ফাইল তৈরি করে।
  2. বিল্ড সিস্টেম 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" অ্যাসেম্বলারের সাথে মিলে যায়। ফিল্টারটি অবশ্যই একটি স্বতন্ত্র শেল কমান্ড হতে হবে যা ইনপুট ফাইলের নামটি তার প্রথম আর্গুমেন্ট হিসাবে নেয় এবং আউটপুট ফাইলের নামটি দ্বিতীয়টি হিসাবে নেয়। যেমন: 

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S

NDK-প্রদত্ত ফাংশন ম্যাক্রো

এই বিভাগে GNU Make ফাংশন ম্যাক্রো ব্যাখ্যা করে যা NDK প্রদান করে। তাদের মূল্যায়ন করতে $(call <function>) ব্যবহার করুন; তারা পাঠ্য তথ্য ফেরত দেয়।

আমার-ডির

এই ম্যাক্রোটি সর্বশেষ অন্তর্ভুক্ত করা মেকফাইলের পথ ফিরিয়ে দেয়, যা সাধারণত বর্তমান Android.mk এর ডিরেক্টরি। my-dir আপনার Android.mk ফাইলের শুরুতে LOCAL_PATH সংজ্ঞায়িত করার জন্য দরকারী। যেমন: 

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 এর পরিবর্তে $PATH/foo হিসাবে সংজ্ঞায়িত করে, কারণ এটিই যেখানে এটির সাম্প্রতিক অন্তর্ভুক্ত রয়েছে।

আপনি 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

সব-সাবডির-মেকফাইল

বর্তমান my-dir পাথের সমস্ত সাবডিরেক্টরিতে অবস্থিত Android.mk ফাইলগুলির তালিকা প্রদান করে৷

আপনি বিল্ড সিস্টেমে ডিপ-নেস্টেড সোর্স ডিরেক্টরি শ্রেণীবিন্যাস প্রদান করতে এই ফাংশনটি ব্যবহার করতে পারেন। ডিফল্টরূপে, NDK শুধুমাত্র Android.mk ফাইল ধারণকারী ডিরেক্টরির ফাইলগুলি সন্ধান করে।

এই-মেকফাইল

বর্তমান মেকফাইলের পাথ ফেরত দেয় (যা থেকে বিল্ড সিস্টেম ফাংশন বলে)।

parent-makefile

ইনক্লুশন ট্রিতে প্যারেন্ট মেকফাইলের পাথ ফেরত দেয় (মেকফাইলের পাথ যা বর্তমানটিকে অন্তর্ভুক্ত করে)।

grand-parent-makefile

অন্তর্ভুক্তি ট্রিতে দাদা-দাদি মেকফাইলের পাথ ফেরত দেয় (মেকফাইলের পাথ যা বর্তমানটি অন্তর্ভুক্ত করে)।

আমদানি-মডিউল

একটি ফাংশন যা আপনাকে মডিউলের নামে একটি মডিউলের Android.mk ফাইল খুঁজে পেতে এবং অন্তর্ভুক্ত করতে দেয়। একটি সাধারণ উদাহরণ নিম্নরূপ: 

$(call import-module,<name>)

এই উদাহরণে, বিল্ড সিস্টেম আপনার NDK_MODULE_PATH এনভায়রনমেন্ট ভেরিয়েবল রেফারেন্সের তালিকায় <name> ট্যাগ করা মডিউলের সন্ধান করে এবং আপনার জন্য স্বয়ংক্রিয়ভাবে এর Android.mk ফাইল অন্তর্ভুক্ত করে।