সুনগ বিল্ড সিস্টেম

অ্যান্ড্রয়েড .0.০ প্রকাশের আগে অ্যান্ড্রয়েড তার বিল্ড বিধিগুলি বর্ণনা ও সম্পাদন করতে একচেটিয়াভাবে জিএনইউ মেক ব্যবহার করেছিল। মেক বিল্ড সিস্টেমটি ব্যাপকভাবে সমর্থিত এবং ব্যবহৃত হয়, তবে অ্যান্ড্রয়েডের স্কেলে ধীর, ত্রুটির প্রবণ, অপরিবর্তনীয় এবং পরীক্ষা করা শক্ত হয়ে ওঠে। সুনগ বিল্ড সিস্টেম অ্যান্ড্রয়েড বিল্ডগুলির জন্য প্রয়োজনীয় নমনীয়তা সরবরাহ করে।

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

সোং কী?

মেক প্রতিস্থাপনের জন্য অ্যান্ড্রয়েড 7.0 (নওগাত) এ সুনগ বিল্ড সিস্টেমটি চালু করা হয়েছিল। এটি অ্যান্ড্রয়েড তৈরির গতি বাড়ানোর জন্য কটি জিএনইউ মেক ক্লোন সরঞ্জাম এবং নিনজা বিল্ড সিস্টেম উপাদানটিকে উপকৃত করে।

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

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

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

এখানে .bp একটি কনফিগারেশন (ব্লুপ্রিন্ট বা। .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 ফাইলগুলি সহজ। এগুলিতে শর্তযুক্ত বা নিয়ন্ত্রণ প্রবাহের বিবরণ নেই; সমস্ত জটিলতা Go তে লিখিত যুক্তি দ্বারা পরিচালিত হয়। সম্ভব হলে, Android.bp ফাইলগুলির বাক্য গঠন এবং শব্দার্থবিদ্যা বাজেল বিল ফাইলগুলির অনুরূপ।

মডিউল

Android.bp ফাইলের একটি মডিউল একটি মডিউল টাইপ দিয়ে শুরু হয় যার name: "value", অনুসারে বৈশিষ্ট্যগুলির সেট name: "value", বিন্যাস:

 cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}
 

প্রতিটি মডিউলের একটি name বৈশিষ্ট্য থাকতে হবে এবং নেমস্পেস এবং প্রি-বিল্ট মডিউলগুলির name বৈশিষ্ট্যগুলি বাদ দিয়ে, সমস্ত Android.bp ফাইলগুলির মধ্যে মানটি অবশ্যই অনন্য হবে which

srcs সম্পত্তি স্ট্রিংয়ের তালিকা হিসাবে মডিউলটি তৈরি করতে ব্যবহৃত উত্স ফাইলগুলি সুনির্দিষ্ট করে। আপনি genrule বা filegroup মতো উত্স ফাইল উত্পাদনকারী অন্যান্য মডিউলগুলির filegroup মডিউল রেফারেন্স সিনট্যাক্স ":<module-name>" ব্যবহার করে উল্লেখ করতে পারেন।

বৈধ মডিউল ধরণের এবং তাদের বৈশিষ্ট্যগুলির তালিকার জন্য, সুনগ মডিউলগুলি দেখুন।

প্রকারভেদ

ভেরিয়েবল এবং বৈশিষ্ট্যগুলি দৃ assign়ভাবে টাইপ করা হয়, প্রথম অ্যাসাইনমেন্টের উপর ভিত্তি করে পরিবর্তনশীল এবং মডিউল টাইপ অনুসারে বৈশিষ্ট্যগুলি স্থিরভাবে সেট করা হয়। সমর্থিত প্রকারগুলি হ'ল:

• বুলিয়ানস ( true বা false )
• পূর্ণসংখ্যার ( int )
• স্ট্রিং ( "string" )
• স্ট্রিংগুলির তালিকা ( ["string1", "string2"] স্ট্রিং 1 ["string1", "string2"] )
• মানচিত্র ( {key1: "value1", key2: ["value2"]} )

মানচিত্রে নেস্টেড মানচিত্র সহ যে কোনও ধরণের মান থাকতে পারে। তালিকাগুলি এবং মানচিত্রে শেষ মানের পরে কমা কমা থাকতে পারে।

Globs

বৈশিষ্ট্যগুলি যা srcs মতো ফাইলগুলির একটি তালিকা srcs , তারাও 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 ফাইলগুলিতে সি-স্টাইলের মাল্টলাইন /* */ এবং সি ++ স্টাইল একক লাইন // মন্তব্য থাকতে পারে।

অপারেটর

স্ট্রিংস, স্ট্রিংগুলির তালিকা এবং মানচিত্রগুলি + অপারেটর ব্যবহার করে যুক্ত করা যেতে পারে। পূর্ণসংখ্যাগুলি + অপারেটর ব্যবহার করে সংক্ষিপ্ত করা যায়। একটি মানচিত্র যুক্ত করা উভয় মানচিত্রে কীগুলির একত্রিত করে, উভয় মানচিত্রে উপস্থিত যে কীগুলির মান সংযোজন করে।

Conditionals কে

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

উদাহরণস্বরূপ, আর্কিটেকচার-নির্দিষ্ট ফাইলগুলিকে সমর্থন করার জন্য:

 cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}
 

ফরম্যাটার

সোং-এ গোফ্টের মতো ব্লুপ্রিন্ট ফাইলগুলির জন্য একটি প্রমিত বিন্যাসক অন্তর্ভুক্ত রয়েছে। বর্তমান ডিরেক্টরিতে সমস্ত 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"],
}
 

প্রাক বিল্ট মডিউল

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

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

অ্যান্ড্রয়েড মেক থেকে সুংকে পুরোপুরি রূপান্তর না করা পর্যন্ত, মেক প্রোডাক্ট কনফিগারেশনকে অবশ্যই একটি PRODUCT_SOONG_NAMESPACES মান নির্দিষ্ট করতে হবে। m কমান্ড দ্বারা বিল্ড করার জন্য সুনং রফতানি করে এমন নামের স্থানের একটি পৃথকীকরণের তালিকা হওয়া উচিত value অ্যান্ড্রয়েডের সুনগে রূপান্তর সম্পূর্ণ হওয়ার পরে, নেমস্পেসগুলি সক্ষম করার বিশদটি পরিবর্তন করতে পারে।

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

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

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

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

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

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