Android.bp फ़ाइल फ़ॉर्मैट

Android.bp फ़ाइलें, डिज़ाइन के हिसाब से आसान होती हैं. इनमें कंडीशनल या कंट्रोल फ़्लो स्टेटमेंट शामिल नहीं होते. सभी जटिलताओं को Go में लिखे गए बिल्ड लॉजिक से मैनेज किया जाता है.

मॉड्यूल

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.

मान्य मॉड्यूल टाइप और उनकी प्रॉपर्टी की सूची देखने के लिए, Soong मॉड्यूल का रेफ़रंस देखें.

प्रकार

वैरिएबल और प्रॉपर्टी को टाइप किया जाता है. वैरिएबल, पहले असाइनमेंट के आधार पर डाइनैमिक होते हैं. वहीं, प्रॉपर्टी को मॉड्यूल टाइप के हिसाब से स्टैटिक तौर पर सेट किया जाता है. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है:

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

मैप में किसी भी तरह की वैल्यू हो सकती हैं. इनमें नेस्ट किए गए मैप भी शामिल हैं. सूचियों और मैप में, आखिरी वैल्यू के बाद कॉमा हो सकते हैं.

Globs

srcs जैसी प्रॉपर्टी, फ़ाइलों की सूची लेती हैं. ये ग्लोब पैटर्न भी ले सकती हैं. ग्लोब पैटर्न में सामान्य यूनीक्स वाइल्डकार्ड * शामिल हो सकता है. उदाहरण के लिए, *.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++ स्टाइल की एक लाइन वाली // टिप्पणियां शामिल हो सकती हैं.

ऑपरेटर

स्ट्रिंग, स्ट्रिंग की सूचियां, और मैप में + ऑपरेटर का इस्तेमाल करके डेटा जोड़ा जा सकता है. + ऑपरेटर का इस्तेमाल करके, पूर्णांकों को जोड़ा जा सकता है. किसी मैप को जोड़ने पर, दोनों मैप में मौजूद कुंजियों का यूनीयन बनता है. साथ ही, दोनों मैप में मौजूद कुंजियों की वैल्यू जुड़ जाती हैं.

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

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

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.

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

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

Soong की मदद से, अलग-अलग डायरेक्ट्री में मौजूद मॉड्यूल के लिए एक ही नाम इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि हर मॉड्यूल को अलग नेमस्पेस में लिखा गया हो. डेवलपर, नेमस्पेस का एलान कर सकते हैं:

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

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

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

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

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

कंडीशनल

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

उदाहरण के लिए, आर्किटेक्चर के हिसाब से फ़ाइलों को सपोर्ट करने के लिए:

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

फ़ॉर्मेटर

Soong में, Blueprint फ़ाइलों के लिए एक कैननिकल फ़ॉर्मेटर शामिल होता है. यह gofmt की तरह काम करता है. मौजूदा डायरेक्ट्री में मौजूद सभी Android.bp फ़ाइलों को फिर से फ़ॉर्मैट करने के लिए, यह कमांड चलाएं:

bpfmt -w .

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