Android के लिए रस्ट मॉड्यूल

सामान्य नियम के तौर पर, rust_* मॉड्यूल की परिभाषाएं इनका पालन करती हैं cc_* का इस्तेमाल और उससे जुड़ी उम्मीदें. मॉड्यूल का एक उदाहरण नीचे दिया गया है रस्ट बाइनरी की परिभाषा:

rust_binary {
    name: "hello_rust",
    crate_name: "hello_rust",
    srcs: ["src/hello_rust.rs"],
    host_supported: true,
}

इस पेज पर rust_* मॉड्यूल की सबसे सामान्य प्रॉपर्टी के बारे में बताया गया है. अलग-अलग तरह के मॉड्यूल और मॉड्यूल की परिभाषाओं के उदाहरण के बारे में ज़्यादा जानने के लिए, बाइनरी मॉड्यूल, लाइब्रेरी मॉड्यूल या टेस्ट मॉड्यूल देखें.

बेसिक मॉड्यूल टाइप

टाइपपरिभाषाअधिक जानकारी के लिए
rust_binaryRust बाइनरी बाइनरी मॉड्यूल पेज
rust_libraryयह Rust लाइब्रेरी बनाता है. साथ ही, rlib और dylib, दोनों वैरिएंट उपलब्ध कराता है. rust_library, लाइब्रेरी मॉड्यूल पेज.
rust_ffiइससे, रस्ट सी लाइब्रेरी बनती है. इस लाइब्रेरी का इस्तेमाल सीसी में किया जा सकता है मॉड्यूल की मदद से, स्टैटिक और शेयर किए गए, दोनों वैरिएंट उपलब्ध कराए जाते हैं. rust_ffi, लाइब्रेरी मॉड्यूल पेज
rust_proc_macroइससे proc-macro Rust लाइब्रेरी बनती है. (ये कंपाइलर प्लग इन की तरह ही होते हैं.) rust_proc_macro, लाइब्रेरी मॉड्यूल पेज
rust_testरस्ट टेस्ट बाइनरी बनाता है, जो स्टैंडर्ड रस्ट टेस्ट हार्नेस. मॉड्यूल की जांच करें पेज
rust_fuzzlibfuzzer का इस्तेमाल करके, Rust फ़ज़ बाइनरी बनाता है. rust_fuzz मॉड्यूल का उदाहरण
rust_protobufसोर्स जनरेट करता है और Rust लाइब्रेरी बनाता है, जो किसी खास प्रोटोबस के लिए इंटरफ़ेस उपलब्ध कराती है. प्रोटोबफ़्स मॉड्यूल और सोर्स जनरेटर पेज
rust_bindgenसोर्स जनरेट करता है और किसी रस्ट लाइब्रेरी, जिसमें C लाइब्रेरी की रस्ट बाइंडिंग होती हैं. Bindgen बाइंडिंग मॉड्यूल और सोर्स जनरेटर पेज

अहम सामान्य प्रॉपर्टी

ये प्रॉपर्टी सभी Android रस्ट में इस्तेमाल की जाती हैं मॉड्यूल. किसी व्यक्ति से जुड़ी कोई अन्य (यूनीक) प्रॉपर्टी रस्ट मॉड्यूल उस मॉड्यूल के पेज पर मौजूद हैं.

नाम

name आपके मॉड्यूल का नाम है. Soong के अन्य मॉड्यूल की तरह, यह Android.bp मॉड्यूल के ज़्यादातर टाइप के लिए यूनीक होना चाहिए. डिफ़ॉल्ट रूप से, आउटपुट के तौर पर name का इस्तेमाल किया जाता है फ़ाइल नाम. अगर आउटपुट फ़ाइल का नाम, मॉड्यूल के नाम से अलग होना चाहिए, तो उसे तय करने के लिए stem प्रॉपर्टी का इस्तेमाल करें.

स्टेम

stem (ज़रूरी नहीं) की मदद से, आउटपुट फ़ाइल के नाम को सीधे तौर पर कंट्रोल किया जा सकता है. हालांकि, इसमें फ़ाइल एक्सटेंशन और अन्य सफ़िक्स शामिल नहीं हैं. उदाहरण के लिए, rust_library_rlib libfoo की स्टेम वैल्यू वाली लाइब्रेरी, libfoo.rlib फ़ाइल बनाती है. अगर आपने stem प्रॉपर्टी के लिए कोई वैल्यू नहीं दी है, तो आउटपुट फ़ाइल का नाम डिफ़ॉल्ट रूप से मॉड्यूल के नाम पर सेट हो जाता है.

जब आप मॉड्यूल नाम को मनचाहे आउटपुट पर सेट नहीं कर पा रहे हों, तब stem फ़ंक्शन का इस्तेमाल करें फ़ाइल नाम. उदाहरण के लिए, log क्रेट के rust_library को नाम दिया गया है liblog_rust, क्योंकि एक liblog cc_library पहले से मौजूद है. इस मामले में stem प्रॉपर्टी का इस्तेमाल करने से यह पक्का होता है कि आउटपुट फ़ाइल का नाम liblog_rust.* के बजाय liblog.* हो.

srcs

srcs में एक सोर्स फ़ाइल होती है, जो आपके मॉड्यूल के एंट्री पॉइंट (आम तौर पर main.rs या lib.rs) को दिखाती है. rustc, कंपाइलेशन के लिए ज़रूरी सभी अन्य सोर्स फ़ाइलों को रिज़ॉल्व और डिस्कवर करता है. इन फ़ाइलों को जनरेट की गई deps फ़ाइल में शामिल किया जाता है.

जब भी हो सके, प्लैटफ़ॉर्म कोड के लिए इस तरह के इस्तेमाल से बचें. ज़्यादा जानकारी के लिए, सोर्स जनरेटर देखें.

crate_name

crate_name, rustc --crate_name की मदद से क्रेट के नाम का मेटाडेटा सेट करता है फ़्लैग करें. लाइब्रेरी बनाने वाले मॉड्यूल के लिए, यह नाम सोर्स में इस्तेमाल किए गए क्रेट के नाम से मेल खाना चाहिए. उदाहरण के लिए, अगर मॉड्यूल libfoo_bar का सोर्स में extern crate foo_bar के तौर पर रेफ़रंस दिया गया है, तो यह ज़रूरी है कि crate_name: "foo_bar" हो.

यह प्रॉपर्टी सभी rust_* मॉड्यूल के लिए आम है, लेकिन मॉड्यूल के लिए यह ज़रूरी है जो रस्ट लाइब्रेरी बनाती हैं (जैसे कि rust_library rust_ffi, rust_bindgen, rust_protobuf, और rust_proc_macro). ये मॉड्यूल crate_name के बीच के संबंध पर rustc की ज़रूरी शर्तों को लागू करता है और आउटपुट फ़ाइल का नाम डालें. ज़्यादा जानकारी के लिए, लाइब्रेरी मॉड्यूल सेक्शन देखें.

लिंट

रस्ट लिंटर सोर्स जनरेटर को छोड़कर, सभी तरह के मॉड्यूल के लिए डिफ़ॉल्ट रूप से चलता है. कुछ लिंट सेट तय किए जाते हैं और उनका इस्तेमाल मॉड्यूल सोर्स की पुष्टि करने के लिए किया जाता है. ऐसे लिंट के लिए संभावित वैल्यू सेट इस तरह के हैं:

  • मॉड्यूल की जगह के आधार पर, लिंट का डिफ़ॉल्ट सेट default
  • android सबसे सख्त लिंट सेट है, जो सभी Android प्लैटफ़ॉर्म कोड पर लागू होता है
  • vendor वेंडर कोड पर लागू किए गए लिंट का एक आसान सेट
  • लिंट से जुड़ी सभी चेतावनियों और गड़बड़ियों को अनदेखा करने के लिए, none

क्लिपी_लिंट्स

क्लिपी लिंटर भी सोर्स जनरेटर को छोड़कर, सभी तरह के मॉड्यूल के लिए डिफ़ॉल्ट रूप से रन करता है. लिंट के कुछ सेट तय किए गए हैं, जिनका इस्तेमाल मॉड्यूल सोर्स की पुष्टि करने के लिए किया जाता है. ये कुछ तरीके हैं जिनकी मदद से, मान:

  • मॉड्यूल की जगह के आधार पर, लिंट का default डिफ़ॉल्ट सेट
  • android सबसे सख्त लिंट सेट, जो Android प्लैटफ़ॉर्म के सभी कोड पर लागू होता है
  • vendor वेंडर कोड पर लागू किए गए लिंट का एक आसान सेट
  • लिंट से जुड़ी सभी चेतावनियों और गड़बड़ियों को अनदेखा करने के लिए, none

वर्शन

edition, रस्ट वर्शन के बारे में बताता है, ताकि इसे इस्तेमाल किया जा सके इस कोड को कंपाइल किया जा रहा है. यह C और C++ के स्टैंडर्ड वर्शन जैसा ही है. मान्य वैल्यू 2015 और 2018 (डिफ़ॉल्ट) हैं.

फ़्लैग

flags में फ़्लैग की स्ट्रिंग की सूची होती है, जिसे कंपाइल करने के दौरान rustc को पास करना होता है.

ld_flags

ld-flags में, सोर्स को कॉम्पाइल करते समय लिंकर को पास करने के लिए, फ़्लैग की स्ट्रिंग की सूची होती है. इन्हें -C linker-args के रस्ट फ़्लैग से पास किया जाता है. clang का इस्तेमाल लिंकर के फ़्रंट-एंड के तौर पर किया जाता है. यह असल लिंकिंग के लिए lld को कॉल करता है.

सुविधाएं

features उन सुविधाओं की स्ट्रिंग सूची है जिन्हें कंपाइलेशन के दौरान चालू करना ज़रूरी है. इसे --cfg 'feature="foo"' की मदद से rustc को भेजा जाता है. ज़्यादातर सुविधाओं को एक साथ जोड़ा जा सकता है. इसलिए, कई मामलों में इसमें सभी डिपेंडेंसी के लिए ज़रूरी मॉड्यूल देखें. हालांकि, अगर सुविधाएं एक-दूसरे से अलग हैं, तो ऐसी सभी बिल्ड फ़ाइलों में अतिरिक्त मॉड्यूल तय करें जो एक-दूसरे से मेल न खाती हों.

cfgs

cfgs में cfg फ़्लैग की स्ट्रिंग सूची होती है, जिसे कंपाइलेशन के दौरान चालू किया जाना है. --cfg foo और --cfg "fizz=buzz" ने इसे rustc को पास किया है.

बिल्ड सिस्टम, खास तौर पर कुछ cfg फ़्लैग अपने-आप सेट करता है इन स्थितियों की सूची नीचे दी गई है:

  • dylib के तौर पर बनाए गए मॉड्यूल में android_dylib cfg सेट होगा.

  • जिन मॉड्यूल में VNDK का इस्तेमाल किया जाएगा उनमें android_vndk cfg सेट होगा. यह है __ANDROID_VNDK__ से मिलता-जुलता C++ की परिभाषा.

स्ट्रिप

strip यह कंट्रोल करता है कि आउटपुट फ़ाइल को हटाया जाए या नहीं (अगर लागू हो). अगर इसे सेट नहीं किया जाता है, तो डिवाइस मॉड्यूल डिफ़ॉल्ट रूप से, मिनी डीबगइफ़ो के अलावा बाकी सभी चीज़ों को हटा देते हैं. होस्ट मॉड्यूल, डिफ़ॉल्ट रूप से किसी भी सिंबल को हटाते नहीं हैं. मान्य वैल्यू में none शामिल हैं स्ट्रिपिंग बंद करने के लिए और all. ज़्यादा वैल्यू, Soong मॉड्यूल के रेफ़रंस में देखी जा सकती हैं.

host_supported

डिवाइस मॉड्यूल के लिए, host_supported पैरामीटर से पता चलता है कि मॉड्यूल को होस्ट वैरिएंट भी देना चाहिए या नहीं.

लाइब्रेरी डिपेंडेंसी तय करना

Rust मॉड्यूल, इन प्रॉपर्टी की मदद से CC और Rust लाइब्रेरी, दोनों पर निर्भर हो सकते हैं:

प्रॉपर्टी का नाम ब्यौरा
rustlibs ऐसे rust_library मॉड्यूल की सूची जो डिपेंडेंसी भी हैं. डिपेंडेंसी का एलान करने के लिए, इस तरीके का इस्तेमाल करें. इससे, बिल्ड सिस्टम को अपनी पसंद का लिंक चुनने में मदद मिलती है. (रस्ट लाइब्रेरी के ख़िलाफ़ लिंक करने पर, नीचे दी गई टेबल देखें)
rlibs ऐसे rust_library मॉड्यूल की सूची जिन्हें स्टैटिक तरीके से लिंक किया जाना चाहिए rlibs के तौर पर. (सावधानी से उपयोग करें; देखें रस्ट लाइब्रेरी से लिंक करते समय, नीचे दिया गया तरीका अपनाएं.
shared_libs cc_library मॉड्यूल की सूची, जिन्हें शेयर की गई लाइब्रेरी के तौर पर डाइनैमिक तौर पर लिंक किया जाना चाहिए.
static_libs ऐसे cc_library मॉड्यूल की सूची जो स्टैटिक होने चाहिए इन्हें स्टैटिक लाइब्रेरी के तौर पर लिंक किया जाता है.
whole_static_libs ऐसे cc_library मॉड्यूल की सूची जो स्टैटिक होने चाहिए को स्टैटिक लाइब्रेरी के तौर पर लिंक किया जाता है और नतीजे वाली लाइब्रेरी में पूरी तरह से शामिल किया जाता है. rust_ffi_static वैरिएंट के लिए, whole_static_libraries को स्टैटिक लाइब्रेरी के संग्रह में शामिल किया जाएगा. rust_library_rlib वैरिएंट के लिए, whole_static_libraries लाइब्रेरी को rlib लाइब्रेरी में बंडल किया जाएगा.

रस्ट लाइब्रेरी से लिंक करते समय, सबसे सही तरीका है, rlibs के बजाय rustlibs प्रॉपर्टी का इस्तेमाल करें या dylibs, अगर आपके पास ऐसा करने का कोई खास कारण न हो. इससे बिल्ड में ताकि रूट मॉड्यूल की ज़रूरत के हिसाब से सही लिंकेज चुना जा सके. और इससे डिपेंडेंसी ट्री में rlib और लाइब्रेरी के dylib वर्शन (जिस वजह से कंपाइलेशन काम नहीं करेगा).

काम न करने वाली और सीमित सहायता के लिए बिल्ड सुविधाएं

सूंग के रस्ट में vendor के लिए सीमित सहायता उपलब्ध है और vendor_ramdisk इमेज और स्नैपशॉट. हालांकि, staticlibs, cdylibs, rlibs और binaries इस्तेमाल किए जा सकते हैं. वेंडर इमेज बिल्ड टारगेट के लिए, android_vndk cfg प्रॉपर्टी सेट की गई. अगर सिस्टम और वेंडर टारगेट के बीच अंतर है, तो कोड में इसका इस्तेमाल किया जा सकता है. rust_proc_macros, इस जानकारी को वेंडर स्नैपशॉट के हिस्से के तौर पर कैप्चर किया गया है; अगर ये पहले से इस्तेमाल किए जा रहे हैं, तो पक्का करें कि उन्हें सही वर्शन-कंट्रोल कर सकता है.

प्रॉडक्ट, VNDK, और रिकवरी इमेज काम नहीं करती हैं.

इंक्रीमेंटल बिल्ड

डेवलपर SOONG_RUSTC_INCREMENTAL को सेट करके, रस्ट सोर्स एनवायरमेंट वैरिएबल को true के लिए सेट किया गया.

चेतावनी: इससे ऐसी बाइनरी बनाने की गारंटी नहीं मिलती है जो उन बाइनरी से मिलती-जुलती हैं और बिल्डबॉट की मदद से जनरेट किए गए होते हैं. फ़ंक्शन या डेटा, जो ऑब्जेक्ट फ़ाइलें अलग हो सकती हैं. जनरेट किए गए आर्टफ़ैक्ट, EngProd इन्फ़्रास्ट्रक्चर से बनाए गए आर्टफ़ैक्ट से 100% मिलते-जुलते हों, यह पक्का करने के लिए इस वैल्यू को सेट न करें.