ডিজাইন অনুযায়ী, Android.bp ফাইলগুলি সহজবোধ্য। এতে কোনও কন্ডিশনাল বা কন্ট্রোল ফ্লো স্টেটমেন্ট থাকে না;
সব জটিলতা Go-তে লেখা বিল্ড লজিক দ্বারা ম্যানেজ করা হয়।
মডিউল
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-এর মতো সোর্স ফাইল তৈরি করে এমন অন্যান্য মডিউলের আউটপুট রেফারেন্স করতে পারেন।
বৈধ মডিউলের ধরন ও তাদের প্রপার্টির তালিকা দেখতে, m soong_docs রান করে জেনারেট করা Soong মডিউল রেফারেন্স দেখুন। আউটপুট out/soong/docs/soong_build.html-এ
হবে।
ধরন
ভেরিয়েবেল ও প্রপার্টি দৃঢ়ভাবে টাইপ করা হয়, যেখানে ভেরিয়েবেল প্রথম অ্যাসাইনমেন্টের উপর ভিত্তি করে ডায়নামিক হয় এবং প্রপার্টি মডিউলের ধরন অনুযায়ী স্ট্যাটিক হিসেবে সেট করা হয়। যেসব ধরনের ফাইল কাজ করে সেগুলি হল:
- বুলিয়ান (
trueবাfalse) - পূর্ণসংখ্যা (
int) - স্ট্রিং (
"string") - স্ট্রিংয়ের তালিকা (
["string1", "string2"]) - Maps (
{key1: "value1", key2: ["value2"]})
ম্যাপে নেস্ট করা ম্যাপ সহ যেকোনও ধরনের ভ্যালু থাকতে পারে। তালিকা এবং ম্যাপে শেষ ভ্যালুর পরে ট্রেলিং কমা থাকতে পারে।
Globs
যেসব প্রপার্টিতে ফাইলের তালিকা থাকে, যেমন srcs, সেগুলিতে গ্লব প্যাটার্নও
থাকতে পারে। গ্লব প্যাটার্নে সাধারণ UNIX ওয়াইল্ডকার্ড * থাকতে পারে, যেমন
*.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++ স্টাইল
সিঙ্গেল-লাইন // কমেন্ট থাকতে পারে।
অপারেটর
+ অপারেটর ব্যবহার করে স্ট্রিং, স্ট্রিংয়ের তালিকা ও ম্যাপ যোগ করা যেতে পারে।
+ অপারেটর ব্যবহার করে পূর্ণসংখ্যা যোগ করা যেতে পারে। একটি ম্যাপ যোগ করলে দুটি ম্যাপের কী-এর ইউনিয়ন তৈরি হয়, দুটি ম্যাপেই উপস্থিত যেকোনও কী-এর ভ্যালু যোগ করে।
ডিফল্ট মডিউল
একাধিক মডিউলে একই প্রপার্টির পুনরাবৃত্তি করতে ডেভেলপাররা ডিফল্ট মডিউল ব্যবহার করতে পারেন। যেমন:
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 ভ্যালু নির্দিষ্ট করতে হবে। এর
ভ্যালু স্পেস দিয়ে আলাদা করা নেমস্পেসের তালিকা হতে হবে যা Soong, Make-এ এক্সপোর্ট করে
যাতে m কমান্ডের মাধ্যমে বিল্ড করা যায়। Android-এর Soong-এ কনভার্ট করার প্রসেস সম্পূর্ণ হওয়ার পরে,
নেমস্পেস চালু করার বিবরণ পরিবর্তন হতে পারে।
Soong বিভিন্ন ডিরেক্টরিতে মডিউলগুলিকে একই নাম নির্দিষ্ট করার ক্ষমতা প্রদান করে, যতক্ষণ না প্রতিটি মডিউল একটি পৃথক নেমস্পেসের মধ্যে ঘোষণা করা হয় ডেভেলপাররা একটি নেমস্পেস ঘোষণা করতে পারেন:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
মনে রাখবেন যে নেমস্পেসে কোনও name প্রপার্টি নেই; এর পাথ অটোমেটিক
এর নাম হিসেবে অ্যাসাইন করা হয়।
ট্রি-তে প্রতিটি Soong মডিউলের লোকেশনের উপর ভিত্তি করে একটি নেমস্পেস অ্যাসাইন করা হয়।
প্রতিটি Soong মডিউলকে বর্তমান ডিরেক্টরি বা সবচেয়ে কাছের পূর্বপুরুষ ডিরেক্টরির Android.bp ফাইলে পাওয়া soong_namespace দ্বারা সংজ্ঞায়িত নেমস্পেসে আছে বলে বিবেচনা করা হয়। এই ধরনের কোনও soong_namespace মডিউল খুঁজে পাওয়া না গেলে, মডিউলটি ইমপ্লিসিট রুট নেমস্পেসে আছে বলে ধরে নেওয়া হয়।
এখানে একটি উদাহরণ দেওয়া হল: Soong, মডিউল M দ্বারা ঘোষিত ডিপেন্ডেন্সি D সমাধান করার চেষ্টা করে যা নেমস্পেস N-এ আছে এবং নেমস্পেস I1, I2, I3… ইমপোর্ট করে।
- তারপর, D যদি
//namespace:moduleফর্মের সম্পূর্ণভাবে উপযুক্ত নাম হয়, তাহলে শুধুমাত্র নির্দিষ্ট মডিউলের নামের জন্য নির্দিষ্ট নেমস্পেস সার্চ করা হয়। - অন্যথায়, Soong প্রথমে D নামের মডিউল খোঁজে যা N নেমস্পেসে ঘোষণা করা হয়েছে।
- সেই মডিউল না থাকলে, Soong, D নামের মডিউল I1, I2, I3… নেমস্পেসে খোঁজে।
- Soong রুট নেমস্পেসে খোঁজে।
শর্তসাপেক্ষ বাক্য
Soong-এ Android.bp ফাইলে কন্ডিশনাল কাজ করে না। পরিবর্তে,
বিল্ড নিয়মের জটিলতা যার জন্য শর্তসাপেক্ষ প্রয়োজন হবে তা Go-তে পরিচালনা করা হয়,
যেখানে উচ্চ-স্তরের ভাষা বৈশিষ্ট্য ব্যবহার করা যেতে পারে, এবং অন্তর্নিহিত নির্ভরতা
শর্তসাপেক্ষ দ্বারা প্রবর্তিত ট্র্যাক করা যেতে পারে. বেশিরভাগ শর্তকে ম্যাপ প্রপার্টিতে কনভার্ট করা হয়, যেখানে ম্যাপের একটি ভ্যালু বেছে নেওয়া হয় এবং টপ-লেভেল প্রপার্টিতে যোগ করা হয়।
যেমন, আর্কিটেকচার-নির্দিষ্ট ফাইল সাপোর্ট করতে:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
ফর্ম্যাটার
Soong-এ ব্লুপ্রিন্ট ফাইলের জন্য একটি ক্যানোনিকাল ফর্ম্যাটার অন্তর্ভুক্ত রয়েছে, যা
gofmt-এর মতো। বর্তমান ডিরেক্টরিতে সব
Android.bp ফাইল রিকার্সিভলি রিফরম্যাট করতে, রান করুন:
bpfmt -w .
ক্যানোনিকাল ফর্ম্যাটে চার-স্পেস ইন্ডেন্ট, মাল্টিএলিমেন্ট তালিকার প্রতিটি এলিমেন্টের পরে নতুন লাইন এবং তালিকা ও ম্যাপে ট্রেলিং কমা অন্তর্ভুক্ত থাকে।