Soong বিল্ড সিস্টেম

অ্যান্ড্রয়েড 7.0 রিলিজের আগে, অ্যান্ড্রয়েড তার বিল্ড নিয়মগুলি বর্ণনা এবং কার্যকর করার জন্য একচেটিয়াভাবে GNU Make ব্যবহার করত। মেক বিল্ড সিস্টেম ব্যাপকভাবে সমর্থিত এবং ব্যবহার করা হয়, কিন্তু অ্যান্ড্রয়েডের স্কেলে ধীর, ত্রুটি প্রবণ, আনস্কেলযোগ্য এবং পরীক্ষা করা কঠিন হয়ে পড়ে। Soong বিল্ড সিস্টেম Android বিল্ডের জন্য প্রয়োজনীয় নমনীয়তা প্রদান করে।

সতর্কতা: Bazel একটি সমর্থিত বিল্ড সিস্টেম নয়। Soong থেকে Bazel-এ পরিকল্পিত বহু-বছরের স্থানান্তর 2023 সালের অক্টোবরে বন্ধ করা হয়েছিল। আপনি কার্নেল তৈরি করতে Bazel ব্যবহার করা চালিয়ে যেতে পারেন, কিন্তু সম্পূর্ণ AOSP বিল্ডের জন্য আপনার Soong ব্যবহার করা উচিত।

এই কারণে, প্ল্যাটফর্ম বিকাশকারীরা যত তাড়াতাড়ি সম্ভব মেক থেকে স্যুইচ করবেন এবং Soong গ্রহণ করবেন বলে আশা করা হচ্ছে। সহায়তা পাওয়ার জন্য অ্যান্ড্রয়েড-বিল্ডিং গুগল গ্রুপে প্রশ্ন পাঠান।

সুং কি?

মেক প্রতিস্থাপনের জন্য Soong বিল্ড সিস্টেমটি Android 7.0 (Nougat) এ চালু করা হয়েছিল। এটি অ্যান্ড্রয়েড তৈরির গতি বাড়ানোর জন্য Kati GNU মেক ক্লোন টুল এবং নিনজা বিল্ড সিস্টেম কম্পোনেন্ট ব্যবহার করে।

সাধারণ নির্দেশাবলীর জন্য অ্যান্ড্রয়েড মেক বিল্ড সিস্টেমের বিবরণ দেখুন অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টে (এওএসপি) এবং মেক থেকে সুং-এ মানিয়ে নেওয়ার জন্য প্রয়োজনীয় পরিবর্তনগুলি সম্পর্কে জানতে Android.mk লেখকদের জন্য সিস্টেম পরিবর্তনগুলি তৈরি করুন ৷

মূল পদের সংজ্ঞা এবং সম্পূর্ণ বিশদ বিবরণের জন্য সুং রেফারেন্স ফাইলগুলির জন্য শব্দকোষে বিল্ড-সম্পর্কিত এন্ট্রিগুলি দেখুন।

সতর্কতা: যতক্ষণ না অ্যান্ড্রয়েড সম্পূর্ণরূপে Make থেকে Soong-এ রূপান্তরিত হয়, ততক্ষণ পর্যন্ত Make পণ্য কনফিগারেশনে PRODUCT_SOONG_NAMESPACES মান নির্দিষ্ট করতে হবে। নির্দেশাবলীর জন্য নেমস্পেস মডিউল বিভাগটি দেখুন।

মেক এবং সুং তুলনা

এখানে একটি Soong কনফিগারেশন (ব্লুপ্রিন্ট বা .bp ) ফাইলে সুং এর সাথে মেক কনফিগারেশনের তুলনা করা হয়েছে।

উদাহরণ তৈরি করুন

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux

LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src

LOCAL_SRC_FILES := $(call \
     all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)

সোং উদাহরণ

cc_library_shared {
     name: "libxmlrpc++",

     rtti: true,
     cppflags: [
           "-Wall",
           "-Werror",
           "-fexceptions",
     ],
     export_include_dirs: ["src"],
     srcs: ["src/**/*.cpp"],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

পরীক্ষা-নির্দিষ্ট সুং কনফিগারেশন উদাহরণের জন্য, সরল বিল্ড কনফিগারেশন দেখুন।

একটি Android.bp ফাইলের ক্ষেত্রগুলির ব্যাখ্যার জন্য, Android.bp ফাইল বিন্যাস দেখুন।

বিশেষ মডিউল

কিছু বিশেষ মডিউল গ্রুপের অনন্য বৈশিষ্ট্য রয়েছে।

ডিফল্ট মডিউল

একটি ডিফল্ট মডিউল একাধিক মডিউলে একই বৈশিষ্ট্য পুনরাবৃত্তি করতে ব্যবহার করা যেতে পারে। যেমন:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

প্রি-বিল্ট মডিউল

কিছু প্রি-বিল্ট মডিউল প্রকার একটি মডিউলকে তার উৎস-ভিত্তিক প্রতিরূপের মতো একই নাম রাখার অনুমতি দেয়। উদাহরণস্বরূপ, foo নামের একটি cc_prebuilt_binary হতে পারে যখন একই নামের একটি cc_binary ইতিমধ্যেই থাকে। এটি বিকাশকারীদের তাদের চূড়ান্ত পণ্যে কোন সংস্করণটি অন্তর্ভুক্ত করতে হবে তা চয়ন করার নমনীয়তা দেয়। যদি একটি বিল্ড কনফিগারেশনে উভয় সংস্করণ থাকে, তবে প্রিবিল্ট মডিউল সংজ্ঞায় prefer পতাকা মান নির্দেশ করে কোন সংস্করণটির অগ্রাধিকার রয়েছে। মনে রাখবেন কিছু প্রি-বিল্ট মডিউলের নাম আছে যেগুলি prebuilt দিয়ে শুরু হয় না, যেমন android_app_import ।

নেমস্পেস মডিউল

যতক্ষণ না Android সম্পূর্ণরূপে Make থেকে Soong-এ রূপান্তরিত না হয়, ততক্ষণ পর্যন্ত Make পণ্য কনফিগারেশনে একটি PRODUCT_SOONG_NAMESPACES মান নির্দিষ্ট করতে হবে। এর মান হওয়া উচিত নেমস্পেসগুলির একটি স্থান-বিচ্ছিন্ন তালিকা যা সুং m কমান্ড দ্বারা তৈরি করতে রপ্তানি করে। Soong-এ অ্যান্ড্রয়েডের রূপান্তর সম্পূর্ণ হওয়ার পরে, নেমস্পেস সক্ষম করার বিবরণ পরিবর্তিত হতে পারে।

যতক্ষণ পর্যন্ত প্রতিটি মডিউল একটি পৃথক নেমস্পেসের মধ্যে ঘোষণা করা হয় ততক্ষণ Soong একই নাম নির্দিষ্ট করার জন্য বিভিন্ন ডিরেক্টরিতে মডিউলগুলির জন্য ক্ষমতা প্রদান করে। একটি নামস্থান এইভাবে ঘোষণা করা যেতে পারে:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

মনে রাখবেন যে একটি নামস্থানের একটি নাম সম্পত্তি নেই; এর পথ স্বয়ংক্রিয়ভাবে এর নাম হিসাবে নির্ধারিত হয়।

প্রতিটি সুং মডিউলকে গাছের অবস্থানের উপর ভিত্তি করে একটি নামস্থান বরাদ্দ করা হয়। প্রতিটি Soong মডিউল বর্তমান ডিরেক্টরি বা নিকটতম পূর্বপুরুষ ডিরেক্টরিতে একটি Android.bp ফাইলে পাওয়া soong_namespace দ্বারা সংজ্ঞায়িত নেমস্পেসে বলে মনে করা হয়। যদি এমন কোনো soong_namespace মডিউল না পাওয়া যায়, তাহলে মডিউলটিকে অন্তর্নিহিত রুট নামস্থানে বিবেচনা করা হয়।

এখানে একটি উদাহরণ: সুং নেমস্পেস এন-এ মডিউল M দ্বারা ঘোষিত নির্ভরতা ডি সমাধান করার চেষ্টা করে যা I1, I2, I3 নামস্থান আমদানি করে...

1. তারপর যদি D ফর্মের একটি সম্পূর্ণ যোগ্য নাম হয় //namespace:module , শুধুমাত্র নির্দিষ্ট নামস্থানটি নির্দিষ্ট মডিউল নামের জন্য অনুসন্ধান করা হয়।
2. অন্যথায়, সুং প্রথমে নামস্থান N-এ ঘোষিত D নামের একটি মডিউল খোঁজে।
3. যদি সেই মডিউলটি বিদ্যমান না থাকে, Soong নামস্থান I1, I2, I3-এ D নামের একটি মডিউল খোঁজে...
4. অবশেষে, সুং মূল নামস্থানে দেখায়।