Google 致力于为黑人社区推动种族平等。查看具体举措
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

सूंग क्या है?

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

सामान्य निर्देशों के लिए Android Open Source Project (AOSP) में Android Make Build System विवरण देखें और Make.m Soong से अनुकूलन के लिए आवश्यक संशोधनों के बारे में जानने के लिए Android.mk राइटर्स के लिए सिस्टम परिवर्तन बनाएँ।

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

बनाओ और Soong तुलना करें

यहाँ Soong कॉन्फ़िगरेशन (ब्लूप्रिंट या .bp ) फ़ाइल में समान पूरा करने वाले Soong के साथ Make कॉन्फ़िगरेशन की तुलना की गई है।

उदाहरण बनाओ

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,
           },
     },
}

परीक्षण-विशिष्ट Soong कॉन्फ़िगरेशन उदाहरणों के लिए सरल बिल्ड कॉन्फ़िगरेशन देखें।

Android.bp फ़ाइल स्वरूप

डिजाइन द्वारा, Android.bp फाइलें सरल हैं। इनमें सशर्त या नियंत्रण प्रवाह विवरण शामिल नहीं हैं; सभी जटिलता को गो में लिखे गए तर्क द्वारा निर्मित किया जाता है। जब संभव हो, Android.bp फ़ाइलों का सिंटैक्स और शब्दार्थ Bazel BUILD फ़ाइलों के समान होता है।

मॉड्यूल

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

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

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

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

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

प्रकार

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

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

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

globs

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

ऑपरेटर्स

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

सशर्त,

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

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

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

फ़ॉर्मेटर

Soong में गोफ़र्ट के समान ब्लूप्रिंट फ़ाइलों के लिए एक कैनोनिकल फॉर्मैटर शामिल है । वर्तमान निर्देशिका में सभी 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_prebuilt_binary नामित foo जब वहाँ पहले से ही एक है cc_binary ही नाम के साथ। यह डेवलपर्स को अपने अंतिम उत्पाद में शामिल करने के लिए कौन सा संस्करण चुनने की सुविधा देता है। निर्माण विन्यास दोनों संस्करणों शामिल है, तो prefer पहले से बनाए गए मॉड्यूल परिभाषा तय कर कौन सा संस्करण प्राथमिकता है में झंडा मूल्य। ध्यान दें कि कुछ प्रीबिल्ट मॉड्यूल में ऐसे नाम होते हैं जो prebuilt शुरू नहीं होते हैं, जैसे कि android_app_import

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

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

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

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

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

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

यहाँ एक उदाहरण है: नामस्थान N में मॉड्यूल M द्वारा घोषित निर्भरता D को हल करने के लिए Soong का प्रयास है कि I1, I2, I3 नामस्थानों को आयात करता है…

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