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

एंड्रॉइड 7.0 रिलीज से पहले, एंड्रॉइड ने अपने निर्माण नियमों का वर्णन करने और निष्पादित करने के लिए विशेष रूप से जीएनयू मेक का उपयोग किया था। मेक बिल्ड सिस्टम व्यापक रूप से समर्थित और उपयोग किया जाता है, लेकिन एंड्रॉइड के पैमाने पर यह धीमा, त्रुटि प्रवण, अनस्केलेबल और परीक्षण करना कठिन हो गया है। सूंग बिल्ड सिस्टम एंड्रॉइड बिल्ड के लिए आवश्यक लचीलापन प्रदान करता है।

इस कारण से, प्लेटफ़ॉर्म डेवलपर्स से अपेक्षा की जाती है कि वे मेक से स्विच करें और जल्द से जल्द सूंग को अपनाएँ। समर्थन प्राप्त करने के लिए एंड्रॉइड-बिल्डिंग Google समूह को प्रश्न भेजें।

सूंग क्या है?

मेक को बदलने के लिए सूंग बिल्ड सिस्टम को एंड्रॉइड 7.0 (नूगट) में पेश किया गया था। यह एंड्रॉइड के निर्माण को गति देने के लिए काटी जीएनयू मेक क्लोन टूल और निंजा बिल्ड सिस्टम घटक का लाभ उठाता है।

सामान्य निर्देशों के लिए एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) में एंड्रॉइड मेक बिल्ड सिस्टम विवरण देखें और मेक से सूंग में अनुकूलित करने के लिए आवश्यक संशोधनों के बारे में जानने के लिए एंड्रॉइड.एमके राइटर्स के लिए बिल्ड सिस्टम परिवर्तन देखें।

मुख्य शब्दों की परिभाषाओं के लिए शब्दावली में बिल्ड-संबंधित प्रविष्टियाँ और संपूर्ण विवरण के लिए सूंग संदर्भ फ़ाइलें देखें।

मेक एंड सूंग तुलना

यहां सूंग कॉन्फ़िगरेशन (ब्लूप्रिंट या .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 फ़ाइलें सरल हैं। उनमें सशर्त या नियंत्रण प्रवाह विवरण शामिल नहीं हैं; सभी जटिलताओं को गो में लिखे गए बिल्ड लॉजिक द्वारा नियंत्रित किया जाता है। जब संभव हो, Android.bp फ़ाइलों का सिंटैक्स और शब्दार्थ बेज़ल बिल्ड फ़ाइलों के समान होता है।

मॉड्यूल

Android.bp फ़ाइल में एक मॉड्यूल एक मॉड्यूल प्रकार से शुरू होता है जिसके बाद name: "value", प्रारूप:

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

प्रत्येक मॉड्यूल में एक name प्रॉपर्टी होनी चाहिए, और नेमस्पेस और प्रीबिल्ट मॉड्यूल में name प्रॉपर्टी मान को छोड़कर, सभी Android.bp फ़ाइलों में मान अद्वितीय होना चाहिए, जो दोहराया जा सकता है।

srcs प्रॉपर्टी मॉड्यूल बनाने के लिए उपयोग की जाने वाली स्रोत फ़ाइलों को स्ट्रिंग्स की सूची के रूप में निर्दिष्ट करती है। आप मॉड्यूल संदर्भ सिंटैक्स ":<module-name>" का उपयोग करके अन्य मॉड्यूल के आउटपुट को संदर्भित कर सकते हैं जो genrule या filegroup जैसे स्रोत फ़ाइलों का उत्पादन करते हैं।

मान्य मॉड्यूल प्रकारों और उनकी संपत्तियों की सूची के लिए, सूंग मॉड्यूल संदर्भ देखें।

प्रकार

वेरिएबल और गुण दृढ़ता से टाइप किए जाते हैं, वेरिएबल गतिशील रूप से पहले असाइनमेंट के आधार पर होते हैं, और गुण मॉड्यूल प्रकार द्वारा स्थिर रूप से सेट होते हैं। समर्थित प्रकार हैं:

• बूलियन्स ( true या false )
• पूर्णांक ( int )
• स्ट्रिंग्स ( "string" )
• स्ट्रिंग्स की सूची ( ["string1", "string2"]
• मानचित्र ( {key1: "value1", key2: ["value2"]}

मानचित्रों में नेस्टेड मानचित्रों सहित किसी भी प्रकार के मान शामिल हो सकते हैं। सूचियों और मानचित्रों में अंतिम मान के बाद अनुगामी अल्पविराम हो सकते हैं।

ग्लब्स

गुण जो फ़ाइलों की सूची लेते हैं, जैसे कि 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++ स्टाइल सिंगल-लाइन // टिप्पणियाँ हो सकती हैं।

ऑपरेटर्स

स्ट्रिंग्स, स्ट्रिंग्स की सूची और मानचित्रों को + ऑपरेटर का उपयोग करके जोड़ा जा सकता है। पूर्णांकों को + ऑपरेटर का उपयोग करके सारांशित किया जा सकता है। किसी मानचित्र को जोड़ने से दोनों मानचित्रों में कुंजियों का मिलन होता है, जिससे दोनों मानचित्रों में मौजूद किसी भी कुंजी के मान जुड़ जाते हैं।

सशर्त,

सूंग Android.bp फ़ाइलों में सशर्त समर्थन नहीं करता है। इसके बजाय, निर्माण नियमों में जटिलता जिसके लिए सशर्त की आवश्यकता होगी, को गो में नियंत्रित किया जाता है, जहां उच्च-स्तरीय भाषा सुविधाओं का उपयोग किया जा सकता है, और सशर्त द्वारा पेश की गई अंतर्निहित निर्भरता को ट्रैक किया जा सकता है। अधिकांश सशर्त मानचित्र संपत्ति में परिवर्तित हो जाते हैं, जहां मानचित्र में मानों में से एक का चयन किया जाता है और शीर्ष-स्तरीय गुणों में जोड़ा जाता है।

उदाहरण के लिए, आर्किटेक्चर-विशिष्ट फ़ाइलों का समर्थन करने के लिए:

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

फ़ॉर्मेटर

सूंग में ब्लूप्रिंट फ़ाइलों के लिए gofmt के समान एक कैनोनिकल फ़ॉर्मेटर शामिल है। वर्तमान निर्देशिका में सभी 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 कमांड द्वारा निर्मित करने के लिए निर्यात करता है। एंड्रॉइड का सूंग में रूपांतरण पूरा होने के बाद, नेमस्पेस को सक्षम करने का विवरण बदल सकता है।

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

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

ध्यान दें कि नेमस्पेस में नाम गुण नहीं होता है; इसका पथ स्वचालित रूप से इसके नाम के रूप में निर्दिष्ट हो जाता है।

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

यहां एक उदाहरण दिया गया है: जल्द ही नेमस्पेस एन में मॉड्यूल एम द्वारा घोषित निर्भरता डी को हल करने का प्रयास किया जाता है जो नेमस्पेस I1, I2, I3 को आयात करता है…

1. फिर यदि D फॉर्म //namespace:module का पूर्णतः योग्य नाम है, तो निर्दिष्ट मॉड्यूल नाम के लिए केवल निर्दिष्ट नामस्थान खोजा जाता है।
2. अन्यथा, सूंग सबसे पहले नेमस्पेस एन में घोषित डी नामक मॉड्यूल की तलाश करता है।
3. यदि वह मॉड्यूल मौजूद नहीं है, तो सूंग नेमस्पेस I1, I2, I3… में D नामक मॉड्यूल की तलाश करता है।
4. अंत में, सूंग रूट नेमस्पेस में दिखता है।