অ্যান্ড্রয়েড 7.0 রিলিজের আগে, অ্যান্ড্রয়েড তার বিল্ড নিয়মগুলি বর্ণনা এবং কার্যকর করার জন্য একচেটিয়াভাবে GNU Make ব্যবহার করত। মেক বিল্ড সিস্টেম ব্যাপকভাবে সমর্থিত এবং ব্যবহার করা হয়, কিন্তু অ্যান্ড্রয়েডের স্কেলে ধীর, ত্রুটি প্রবণ, আনস্কেলযোগ্য এবং পরীক্ষা করা কঠিন হয়ে পড়ে। Soong বিল্ড সিস্টেম Android বিল্ডের জন্য প্রয়োজনীয় নমনীয়তা প্রদান করে।
এই কারণে, প্ল্যাটফর্ম বিকাশকারীরা যত তাড়াতাড়ি সম্ভব মেক থেকে স্যুইচ করবেন এবং Soong গ্রহণ করবেন বলে আশা করা হচ্ছে। সহায়তা পাওয়ার জন্য অ্যান্ড্রয়েড-বিল্ডিং গুগল গ্রুপে প্রশ্ন পাঠান।
সুং কি?
মেক প্রতিস্থাপনের জন্য Soong বিল্ড সিস্টেমটি Android 7.0 (Nougat) এ চালু করা হয়েছিল। এটি অ্যান্ড্রয়েড তৈরির গতি বাড়ানোর জন্য Kati GNU মেক ক্লোন টুল এবং নিনজা বিল্ড সিস্টেম কম্পোনেন্ট ব্যবহার করে।
সাধারণ নির্দেশাবলীর জন্য অ্যান্ড্রয়েড মেক বিল্ড সিস্টেমের বিবরণ দেখুন অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টে (এওএসপি) এবং মেক থেকে সুং-এ মানিয়ে নেওয়ার জন্য প্রয়োজনীয় পরিবর্তনগুলি সম্পর্কে জানতে Android.mk লেখকদের জন্য সিস্টেম পরিবর্তনগুলি তৈরি করুন ৷
মূল পদের সংজ্ঞা এবং সম্পূর্ণ বিশদ বিবরণের জন্য সুং রেফারেন্স ফাইলগুলির জন্য শব্দকোষে বিল্ড-সম্পর্কিত এন্ট্রিগুলি দেখুন।
মেক এবং সুং তুলনা
এখানে একটি 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
ফাইলগুলি সহজ। তারা শর্তাধীন বা নিয়ন্ত্রণ প্রবাহ বিবৃতি ধারণ করে না; সমস্ত জটিলতা গো-তে লেখা বিল্ড লজিক দ্বারা পরিচালিত হয়। যখন সম্ভব, Android.bp
ফাইলের বাক্য গঠন এবং শব্দার্থবিদ্যা Bazel BUILD ফাইলের মতো।
মডিউল
একটি Android.bp
ফাইলের একটি মডিউল একটি মডিউল টাইপ দিয়ে শুরু হয় এবং তারপরে name: "value",
বিন্যাস:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
প্রতিটি মডিউলের অবশ্যই একটি name
বৈশিষ্ট্য থাকতে হবে, এবং মানটি অবশ্যই সমস্ত Android.bp
ফাইল জুড়ে অনন্য হতে হবে, নামস্থান এবং পূর্বনির্মাণ মডিউলগুলিতে name
সম্পত্তির মানগুলি ব্যতীত, যা পুনরাবৃত্তি হতে পারে৷
srcs
বৈশিষ্ট্য স্ট্রিংগুলির একটি তালিকা হিসাবে মডিউল তৈরি করতে ব্যবহৃত উত্স ফাইলগুলিকে নির্দিষ্ট করে। আপনি মডিউল রেফারেন্স সিনট্যাক্স ":<module-name>"
ব্যবহার করে উৎস ফাইল তৈরি করে এমন অন্যান্য মডিউলের আউটপুট উল্লেখ করতে পারেন, যেমন genrule
বা filegroup
।
বৈধ মডিউল প্রকার এবং তাদের বৈশিষ্ট্যগুলির একটি তালিকার জন্য, সুং মডিউল রেফারেন্স দেখুন।
প্রকারভেদ
ভেরিয়েবল এবং বৈশিষ্ট্যগুলি দৃঢ়ভাবে টাইপ করা হয়, গতিশীলভাবে প্রথম অ্যাসাইনমেন্টের উপর ভিত্তি করে ভেরিয়েবল এবং বৈশিষ্ট্যগুলি মডিউল টাইপ দ্বারা স্থিরভাবে সেট করা হয়। সমর্থিত প্রকারগুলি হল:
- বুলিয়ানস (
true
বাfalse
) - পূর্ণসংখ্যা (
int
) - স্ট্রিংস (
"string"
) - স্ট্রিংগুলির তালিকা (
["string1", "string2"]
) - মানচিত্র (
{key1: "value1", key2: ["value2"]}
)
মানচিত্রে নেস্টেড মানচিত্র সহ যেকোনো ধরনের মান থাকতে পারে। তালিকা এবং মানচিত্রে শেষ মানের পরে কমা থাকতে পারে।
গ্লবস
যে বৈশিষ্ট্যগুলি ফাইলগুলির একটি তালিকা নেয়, যেমন srcs
, এছাড়াও গ্লোব প্যাটার্ন নিতে পারে। গ্লোব প্যাটার্নে সাধারণ ইউনিক্স ওয়াইল্ডকার্ড *
থাকতে পারে, উদাহরণস্বরূপ *.java
। গ্লোব প্যাটার্নে পাথ এলিমেন্ট হিসেবে একটি একক **
ওয়াইল্ডকার্ডও থাকতে পারে, যা শূন্য বা তার বেশি পাথ উপাদানের সাথে মেলে। উদাহরণস্বরূপ, java/**/*.java
java/Main.java
এবং java/com/android/Main.java
প্যাটার্ন উভয়ের সাথে মিলে যায়।
ভেরিয়েবল
একটি Android.bp
ফাইলে শীর্ষ-স্তরের পরিবর্তনশীল অ্যাসাইনমেন্ট থাকতে পারে:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
ভেরিয়েবলগুলিকে তারা যে ফাইলে ঘোষণা করা হয়েছে তার বাকি অংশে, সেইসাথে যেকোন চাইল্ড ব্লুপ্রিন্ট ফাইলগুলিতে স্কোপ করা হয়েছে৷ ভেরিয়েবলগুলি একটি ব্যতিক্রমের সাথে অপরিবর্তনীয়: এগুলিকে একটি +=
অ্যাসাইনমেন্টের সাথে যুক্ত করা যেতে পারে, তবে শুধুমাত্র তাদের উল্লেখ করার আগে।
মন্তব্য
Android.bp
ফাইলে C-স্টাইল মাল্টিলাইন /* */
এবং C++ স্টাইলের সিঙ্গেল-লাইন //
মন্তব্য থাকতে পারে।
অপারেটর
+ অপারেটর ব্যবহার করে স্ট্রিং, স্ট্রিংয়ের তালিকা এবং মানচিত্র যুক্ত করা যেতে পারে। +
অপারেটর ব্যবহার করে পূর্ণসংখ্যা যোগ করা যেতে পারে। একটি মানচিত্র যুক্ত করা উভয় মানচিত্রে কীগুলির মিলন তৈরি করে, উভয় মানচিত্রে উপস্থিত যেকোনো কীগুলির মান যুক্ত করে।
শর্তাবলী
Soong Android.bp
ফাইলে শর্তসাপেক্ষে সমর্থন করে না। পরিবর্তে, শর্তসাপেক্ষ প্রয়োজন হবে এমন বিল্ড নিয়মের জটিলতা Go-তে পরিচালনা করা হয়, যেখানে উচ্চ-স্তরের ভাষা বৈশিষ্ট্যগুলি ব্যবহার করা যেতে পারে এবং শর্তাবলী দ্বারা প্রবর্তিত অন্তর্নিহিত নির্ভরতাগুলি ট্র্যাক করা যেতে পারে। বেশিরভাগ শর্তসাপেক্ষে মানচিত্র বৈশিষ্ট্যে রূপান্তরিত হয়, যেখানে মানচিত্রের মানগুলির মধ্যে একটি নির্বাচন করা হয় এবং শীর্ষ-স্তরের বৈশিষ্ট্যগুলিতে যুক্ত করা হয়।
উদাহরণস্বরূপ, আর্কিটেকচার-নির্দিষ্ট ফাইল সমর্থন করতে:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
ফরম্যাটার
Soong ব্লুপ্রিন্ট ফাইলগুলির জন্য একটি ক্যানোনিকাল ফর্ম্যাটার অন্তর্ভুক্ত করে, যা gofmt- এর মতো। বর্তমান ডিরেক্টরির সমস্ত Android.bp
ফাইলগুলিকে পুনঃফর্ম্যাট করতে, চালান:
bpfmt -w .
ক্যানোনিকাল ফরম্যাটে চার-স্পেস ইন্ডেন্ট, একটি মাল্টিলিমেন্ট তালিকার প্রতিটি উপাদানের পরে নতুন লাইন এবং তালিকা এবং মানচিত্রে একটি ট্রেলিং কমা অন্তর্ভুক্ত রয়েছে।
বিশেষ মডিউল
কিছু বিশেষ মডিউল গ্রুপের অনন্য বৈশিষ্ট্য রয়েছে।
ডিফল্ট মডিউল
একটি ডিফল্ট মডিউল একাধিক মডিউলে একই বৈশিষ্ট্য পুনরাবৃত্তি করতে ব্যবহার করা যেতে পারে। উদাহরণ স্বরূপ:
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
।
নেমস্পেস মডিউল
যতক্ষণ না অ্যান্ড্রয়েড সম্পূর্ণরূপে Make থেকে Soong-এ রূপান্তরিত হয়, ততক্ষণ পর্যন্ত Make পণ্য কনফিগারেশনে একটি PRODUCT_SOONG_NAMESPACES
মান নির্দিষ্ট করতে হবে। এর মান হওয়া উচিত নেমস্পেসগুলির একটি স্থান-বিচ্ছিন্ন তালিকা যা সুং m
কমান্ড দ্বারা তৈরি করতে রপ্তানি করে। Soong-এ অ্যান্ড্রয়েডের রূপান্তর সম্পূর্ণ হওয়ার পরে, নেমস্পেস সক্ষম করার বিবরণ পরিবর্তিত হতে পারে।
যতক্ষণ প্রতিটি মডিউল একটি পৃথক নেমস্পেসের মধ্যে ঘোষণা করা হয় ততক্ষণ সুং একই নাম নির্দিষ্ট করার জন্য বিভিন্ন ডিরেক্টরিতে মডিউলগুলির জন্য ক্ষমতা প্রদান করে। একটি নামস্থান এইভাবে ঘোষণা করা যেতে পারে:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
মনে রাখবেন যে একটি নামস্থানের একটি নাম সম্পত্তি নেই; এর পথ স্বয়ংক্রিয়ভাবে এর নাম হিসাবে নির্ধারিত হয়।
প্রতিটি সুং মডিউলকে গাছের অবস্থানের উপর ভিত্তি করে একটি নামস্থান বরাদ্দ করা হয়। প্রতিটি Soong মডিউল বর্তমান ডিরেক্টরি বা নিকটতম পূর্বপুরুষ ডিরেক্টরিতে একটি Android.bp
ফাইলে পাওয়া soong_namespace
দ্বারা সংজ্ঞায়িত নেমস্পেসে বলে মনে করা হয়। যদি এমন কোনো soong_namespace
মডিউল না পাওয়া যায়, তাহলে মডিউলটিকে অন্তর্নিহিত রুট নামস্থানে বিবেচনা করা হয়।
এখানে একটি উদাহরণ: সুং নেমস্পেস এন-এ মডিউল M দ্বারা ঘোষিত নির্ভরতা ডি সমাধান করার চেষ্টা করে যা I1, I2, I3 নামস্থান আমদানি করে...
- তারপর যদি D ফর্মের একটি সম্পূর্ণ যোগ্য নাম হয়
//namespace:module
, শুধুমাত্র নির্দিষ্ট নামস্থানটি নির্দিষ্ট মডিউল নামের জন্য অনুসন্ধান করা হয়। - অন্যথায়, সুং প্রথমে নামস্থান N-এ ঘোষিত D নামের একটি মডিউল খোঁজে।
- যদি সেই মডিউলটি বিদ্যমান না থাকে, Soong নামস্থান I1, I2, I3-এ D নামের একটি মডিউল খোঁজে...
- অবশেষে, সুং মূল নামস্থানে দেখায়।