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

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

इस कारण से, प्लेटफ़ॉर्म डेवलपर्स को जल्द से जल्द मेक से स्विच करने और जल्द से जल्द अपनाने की उम्मीद है। सहायता प्राप्त करने के लिए android-build Google Group को प्रश्न भेजें।

सूंग क्या है?

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

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

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

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

यहाँ मेक कॉन्फिगरेशन की तुलना Soong के साथ Soong कॉन्फिगरेशन (ब्लूप्रिंट या .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 फ़ाइलों का सिंटैक्स और शब्दार्थ Bazel BUILD फ़ाइलों के समान होता है।

मॉड्यूल

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

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

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

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 फाइलों में सी-स्टाइल मल्टीलाइन /* */ और सी++ स्टाइल सिंगल-लाइन // टिप्पणियां हो सकती हैं।

ऑपरेटर्स

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

सशर्त,

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

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

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

फ़ॉर्मेटर

Soong में 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"],
}

पूर्वनिर्मित मॉड्यूल

कुछ प्रीबिल्ट मॉड्यूल प्रकार एक मॉड्यूल को उसके स्रोत-आधारित समकक्षों के समान नाम रखने की अनुमति देते हैं। उदाहरण के लिए, foo नाम का एक cc_prebuilt_binary हो सकता है जब पहले से ही समान नाम वाला cc_binary हो। यह डेवलपर्स को यह चुनने की सुविधा देता है कि उनके अंतिम उत्पाद में कौन सा संस्करण शामिल किया जाए। यदि किसी बिल्ड कॉन्फ़िगरेशन में दोनों संस्करण होते हैं, तो प्रीबिल्ट मॉड्यूल परिभाषा में prefer ध्वज मान निर्धारित करता है कि किस संस्करण की प्राथमिकता है। ध्यान दें कि कुछ प्रीबिल्ट मॉड्यूल में ऐसे नाम होते हैं जो prebuilt से शुरू नहीं होते हैं, जैसे android_app_import ।

नेमस्पेस मॉड्यूल

जब तक Android Make से Soong में पूरी तरह से रूपांतरित नहीं हो जाता, तब तक Make उत्पाद कॉन्फ़िगरेशन में PRODUCT_SOONG_NAMESPACES मान निर्दिष्ट होना चाहिए। इसका मान नामस्थानों की एक स्थान-पृथक सूची होना चाहिए जिसे सूंग m कमांड द्वारा निर्मित करने के लिए मेक को निर्यात करता है। सूंग में Android का रूपांतरण पूरा होने के बाद, नाम स्थान को सक्षम करने का विवरण बदल सकता है।

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

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

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

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

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

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