উৎস জেনারেটর

এই পৃষ্ঠাটি কিভাবে উত্পন্ন উৎস সমর্থিত হয় এবং এটি বিল্ড সিস্টেমে কীভাবে ব্যবহার করা যেতে পারে তার একটি উচ্চ-স্তরের দৃশ্য প্রদান করে।

সমস্ত উৎস জেনারেটর একই ধরনের বিল্ড-সিস্টেম কার্যকারিতা প্রদান করে। তিনটি বিল্ড-সিস্টেম সমর্থিত সোর্স-জেনারেশন ব্যবহারের ক্ষেত্রে বিন্ডজেন, এআইডিএল ইন্টারফেস এবং প্রোটোবাফ ইন্টারফেস ব্যবহার করে সি বাইন্ডিং তৈরি করছে।

উৎপন্ন উৎস থেকে ক্রেট

সোর্স কোড তৈরি করে এমন প্রতিটি রাস্ট মডিউল একটি ক্রেট হিসাবে ব্যবহার করা যেতে পারে, ঠিক যেন এটি একটি rust_library হিসাবে সংজ্ঞায়িত করা হয়েছে। (এর মানে এটি rustlibs , rlibs , এবং dylibs বৈশিষ্ট্যগুলিতে একটি নির্ভরতা হিসাবে সংজ্ঞায়িত করা যেতে পারে।) প্ল্যাটফর্ম কোডের জন্য সর্বোত্তম ব্যবহার প্যাটার্ন হল ক্রেট হিসাবে উত্পন্ন উত্সকে নিয়োগ করা। যদিও include! ম্যাক্রো জেনারেটেড সোর্সের জন্য সমর্থিত, এর প্রাথমিক উদ্দেশ্য হল external/ এ থাকা তৃতীয় পক্ষের কোডকে সমর্থন করা।

এমন কিছু ক্ষেত্রে রয়েছে যেখানে প্ল্যাটফর্ম কোড এখনও include!() ম্যাক্রোর মাধ্যমে তৈরি উত্স ব্যবহার করতে পারে, যেমন আপনি যখন একটি অনন্য ফ্যাশনে উত্স তৈরি করতে একটি genrule মডিউল ব্যবহার করেন।

উৎপন্ন উৎস অন্তর্ভুক্ত করতে অন্তর্ভুক্ত!() ব্যবহার করুন

একটি ক্রেট হিসাবে উত্পন্ন উত্স ব্যবহার প্রতিটি নির্দিষ্ট (স্বতন্ত্র) মডিউল পৃষ্ঠায় উদাহরণ দ্বারা আচ্ছাদিত করা হয়. এই বিভাগটি দেখায় কিভাবে include!() ম্যাক্রোর মাধ্যমে উত্পন্ন উত্স উল্লেখ করতে হয়। মনে রাখবেন যে এই প্রক্রিয়াটি সমস্ত উত্স জেনারেটরের জন্য অনুরূপ।

পূর্বশর্ত

এই উদাহরণটি এই ধারণার উপর ভিত্তি করে তৈরি করা হয়েছে যে আপনি একটি rust_bindgen মডিউল ( libbuzz_bindgen ) সংজ্ঞায়িত করেছেন এবং include!() ম্যাক্রো ব্যবহার করার জন্য উত্পন্ন উত্স অন্তর্ভুক্ত করার জন্য ধাপে যেতে পারেন। যদি আপনার না থাকে, অনুগ্রহ করে একটি rust bindgen মডিউল নির্ধারণে যান, libbuzz_bindgen তৈরি করুন, তারপর এখানে ফিরে আসুন।

নোট করুন যে এর বিল্ড-ফাইল অংশগুলি সমস্ত উত্স জেনারেটরের জন্য প্রযোজ্য।

উত্পন্ন উত্স অন্তর্ভুক্ত করার জন্য পদক্ষেপ

নিম্নলিখিত বিষয়বস্তু সহ external/rust/hello_bindgen/Android.bp তৈরি করুন:

rust_binary {
   name: "hello_bzip_bindgen_include",
   srcs: [
         // The primary rust source file must come first in this list.
         "src/lib.rs",

         // The module providing the bindgen bindings is
         // included in srcs prepended by ":".
         ":libbuzz_bindgen",
    ],

    // Dependencies need to be redeclared when generated source is used via srcs.
    shared_libs: [
        "libbuzz",
    ],
}

নিম্নলিখিত বিষয়বস্তু সহ external/rust/hello_bindgen/src/bindings.rs তৈরি করুন:

#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]

// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));

নিম্নলিখিত বিষয়বস্তু সহ external/rust/hello_bindgen/src/lib.rs তৈরি করুন:

mod bindings;

fn main() {
    let mut x = bindings::foo { x: 2 };
    unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}

কেন উত্পন্ন উত্স জন্য crates

C/C++ কম্পাইলার থেকে ভিন্ন, rustc শুধুমাত্র একটি একক উৎস ফাইল গ্রহণ করে যা একটি বাইনারি বা লাইব্রেরিতে একটি এন্ট্রি পয়েন্ট উপস্থাপন করে। এটি আশা করে যে সোর্স ট্রিটি এমনভাবে গঠন করা হয়েছে যাতে সমস্ত প্রয়োজনীয় সোর্স ফাইল স্বয়ংক্রিয়ভাবে আবিষ্কার করা যায়। এর মানে হল যে উত্পন্ন উত্স অবশ্যই উত্স গাছে স্থাপন করতে হবে, বা উত্সে অন্তর্ভুক্ত নির্দেশের মাধ্যমে সরবরাহ করতে হবে:

include!("/path/to/hello.rs");

মরিচা সম্প্রদায় এই পার্থক্যের সাথে কাজ করার জন্য build.rs স্ক্রিপ্ট এবং কার্গো বিল্ড পরিবেশ সম্পর্কে অনুমানের উপর নির্ভর করে। যখন এটি তৈরি হয়, cargo কমান্ড একটি OUT_DIR এনভায়রনমেন্ট ভেরিয়েবল সেট করে যার মধ্যে build.rs স্ক্রিপ্টগুলি জেনারেটেড সোর্স কোড স্থাপন করবে বলে আশা করা হয়। সোর্স কোড অন্তর্ভুক্ত করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

include!(concat!(env!("OUT_DIR"), "/hello.rs"));

এটি Soong-এর জন্য একটি চ্যালেঞ্জ উপস্থাপন করে কারণ প্রতিটি মডিউলের আউটপুটগুলি তাদের নিজস্ব out/ ডিরেক্টরি ¹ এ স্থাপন করা হয়। এমন একটি OUT_DIR নেই যেখানে নির্ভরতাগুলি তাদের উৎপন্ন উত্স আউটপুট করে।

প্ল্যাটফর্ম কোডের জন্য, AOSP প্যাকেজিং উৎপন্ন উৎসকে একটি ক্রেটে পছন্দ করে যা আমদানি করা যেতে পারে, বিভিন্ন কারণে:

• উত্পন্ন উত্স ফাইল নাম সংঘর্ষ থেকে প্রতিরোধ করুন.
• রক্ষণাবেক্ষণের প্রয়োজন জুড়ে বয়লারপ্লেট কোড চেক-ইন কম করুন। যেকোন বয়লারপ্লেট যা জেনারেটেড সোর্সকে একটি ক্রেটে কম্পাইল করার জন্য প্রয়োজন হয় তা কেন্দ্রীয়ভাবে রক্ষণাবেক্ষণ করা যেতে পারে।
• জেনারেট করা কোড এবং আশেপাশের ক্রেটের মধ্যে অন্তর্নিহিত ^2টি মিথস্ক্রিয়া এড়িয়ে চলুন।
• সাধারণত ব্যবহৃত উৎপন্ন উত্সগুলিকে গতিশীলভাবে সংযুক্ত করে মেমরি এবং ডিস্কের উপর চাপ কমায়৷

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