Google is committed to advancing racial equity for Black communities. See how.
This page was translated by the 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 to 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

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

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

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

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

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

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

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

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