सूंग बिल्ड सिस्टम

Android 7.0 रिलीज़ से पहले, Android ने बिल्ड के नियमों के बारे में जानकारी देने और उन्हें लागू करने के लिए खास तौर पर GNU Make का इस्तेमाल किया था. बनाएं बिल्ड सिस्टम बड़े पैमाने पर काम करता है और इस्तेमाल किया जा रहा है. हालांकि, यह Android बड़े पैमाने पर धीरे-धीरे काम कर रहा है. इसमें गड़बड़ी की संभावना ज़्यादा होती है, इसे बड़े स्तर पर इस्तेमाल नहीं किया जा सकता, और इसकी जांच करना मुश्किल हो गया है. Soong बिल्ड सिस्टम, Android बिल्ड के लिए ज़रूरी सुविधा देता है.

इस वजह से, प्लैटफ़ॉर्म डेवलपर को जल्द से जल्द, Make की जगह से स्विच करने और Soong का इस्तेमाल करने की उम्मीद करनी चाहिए. सहायता पाने के लिए android-बिल्डिंग 'Google ग्रुप' को सवाल भेजें.

सूंग क्या है?

Make की जगह सूंग का बिल्ड सिस्टम इस्तेमाल करने के लिए, Android 7.0 (Nougat) में नया सिस्टम पेश किया गया था. यह Android के बिल्ड को तेज़ी से पूरा करने के लिए, Kati GNU मेक क्लोन टूल और Ninja सिस्टम कॉम्पोनेंट का इस्तेमाल करता है.

सामान्य निर्देशों और Android.mk Writers के लिए सिस्टम में बदलाव बनाने की जानकारी के लिए, Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में Android Make Build System से जुड़ा ब्यौरा देखें. इससे आपको उन बदलावों के बारे में जानकारी मिलेगी जो Make to Sung में लागू होंगे.

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

बनाएं और सूंग की तुलना करें

यहां एक तुलना दी गई है कि 'मेक कॉन्फ़िगरेशन' और सूंग के साथ मिलकर, यूंग कॉन्फ़िगरेशन (ब्लूप्रिंट या .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 फ़ाइल फ़ॉर्मैट देखें.

खास मॉड्यूल

कुछ खास मॉड्यूल ग्रुप में खास विशेषताएं होती हैं.

डिफ़ॉल्ट मॉड्यूल

एक ही प्रॉपर्टी को कई मॉड्यूल में दोहराने के लिए, डिफ़ॉल्ट मॉड्यूल का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

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.

Namespace मॉड्यूल

जब तक Android पूरी तरह से, मेक से सूंग में नहीं बदल जाता, तब तक 'प्रॉडक्ट बनाएं' कॉन्फ़िगरेशन में PRODUCT_SOONG_NAMESPACES की वैल्यू तय करना ज़रूरी है. इसकी वैल्यू, नेमस्पेस की स्पेस से अलग की गई सूची में होनी चाहिए, जिसे सूंग m कमांड की मदद से बनाया जाता है. इसे 'मेकटू' में एक्सपोर्ट किया जाता है. Android का सूंग में बदलाव पूरा होने के बाद, नेमस्पेस चालू करने की जानकारी बदल सकती है.

सूंग, अलग-अलग डायरेक्ट्री में मॉड्यूल के लिए एक ही नाम बताने की सुविधा देता है, बशर्ते हर मॉड्यूल का एलान एक अलग नेमस्पेस में किया गया हो. नाम स्थान को इस तरह से घोषित किया जा सकता है:

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

ध्यान दें कि नेमस्पेस में नाम प्रॉपर्टी नहीं होती; इसका पाथ अपने-आप इसके नाम के तौर पर असाइन हो जाता है.

हर सूंग मॉड्यूल को पेड़ में उसकी जगह के आधार पर एक नेमस्पेस असाइन किया जाता है. हर सूंग मॉड्यूल को soong_namespace के तय किए गए नेमस्पेस में माना जाता है. यह मौजूदा डायरेक्ट्री या सबसे नज़दीकी एंसेस्टर डायरेक्ट्री में मौजूद Android.bp फ़ाइल में मौजूद होता है. अगर ऐसा कोई soong_namespace मॉड्यूल नहीं मिलता है, तो मॉड्यूल को इंप्लिसिट रूट नेमस्पेस में माना जाता है.

यहां एक उदाहरण दिया गया है: सूंग, नेमस्पेस N में मॉड्यूल M के ज़रिए एलान की गई डिपेंडेंसी D को हल करने की कोशिश करता है, जो नेमस्पेस I1, I2, I3 इंपोर्ट करता है...

1. इसके बाद, अगर D फ़ॉर्म //namespace:module का पूरी तरह क्वालिफ़ाइड नाम है, तो बताए गए मॉड्यूल नाम के लिए सिर्फ़ खास नाम स्थान की खोज की जाती है.
2. ऐसा नहीं करने पर, सूंग पहले नेमस्पेस N में बताया गया D नाम का मॉड्यूल ढूंढता है.
3. अगर वह मॉड्यूल मौजूद नहीं है, तो सूंग नाम स्पेस I1, I2, I3 में D नाम का मॉड्यूल ढूंढता है...
4. आखिर में, सूंग रूट नेमस्पेस में दिखता है.