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

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

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

प्रकार

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

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

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

ग्लॉब

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++ स्टाइल की एक लाइन वाली // टिप्पणियां हो सकती हैं.

ऑपरेटर

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

कंडीशनल

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

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

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

फ़ॉर्मैटर

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

bpfmt -w .

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