डिपेंडेंसी

अगर A को बिल्ड या रन करने के समय B की ज़रूरत है, तो टारगेट A, टारगेट B पर निर्भर करता है. इस पर निर्भर करता है संबंध, टारगेट पर डायरेक्टेड ऐसाइक्लिक ग्राफ़ (डीएजी) बनाता है. इसे डिपेंडेंसी ग्राफ़ कहा जाता है.

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

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

असल और बताई गई डिपेंडेंसी

X को सही तरीके से बनाने के लिए, Y मौजूद होने, बिल्ट-इन, और अप-टू-डेट होने पर, टारगेट X, टारगेट Y पर पूरी तरह से निर्भर होता है. पहले से मौजूद का मतलब जनरेट, प्रोसेस, कंपाइल, लिंक, संग्रहित, कंप्रेस किए गए, लागू किए गए या किसी ऐसे टास्क से हो सकता है जो आम तौर पर बिल्ड के दौरान होता है.

अगर X के पैकेज में, X के पैकेज में X से Y डिपेंडेंसी है, तो टारगेट X में डिपेंडेंसी टारगेट Y पर सेट होती है.

सही बिल्ड के लिए, असल डिपेंडेंसी A का ग्राफ़, एलान किए गए डिपेंडेंसी D के ग्राफ़ का सबग्राफ़ होना चाहिए. इसका मतलब है कि A में सीधे तौर पर जुड़े नोड x --> y के हर जोड़े को D में भी सीधे तौर पर जोड़ा जाना चाहिए. यह कहा जा सकता है कि D, A का ज़्यादा अनुमान है.

BUILD फ़ाइल राइटर को बिल्ड सिस्टम पर लागू होने वाले हर नियम के लिए, सभी नियमों के लिए सीधे तौर पर निर्भर होने की पूरी जानकारी साफ़ तौर पर देनी होगी.

इस सिद्धांत का पालन न करने पर, अनिश्चित व्यवहार होता है: हो सकता है कि बिल्ड न हो पाए, लेकिन इससे भी बुरा यह हो सकता है कि बिल्ड, कुछ पहले की कार्रवाइयों पर निर्भर हो या टारगेट में मौजूद, ट्रांज़िशन वाली डिपेंडेंसी पर निर्भर हो. Bazel, ग़ैर-मौजूद डिपेंडेंसी की जांच करता है और गड़बड़ियों की रिपोर्ट करता है. हालांकि, यह मुमकिन नहीं है कि यह जांच सभी मामलों में पूरी हो.

आपको सीधे तौर पर इंपोर्ट नहीं की गई हर चीज़ को सूची में शामिल करने की ज़रूरत नहीं है. ऐसा करने की कोशिश भी नहीं करनी चाहिए. भले ही, A को प्रोसेस करने के समय, इसकी ज़रूरत हो.

टारगेट X के बिल्ड के दौरान, बिल्ड टूल X की डिपेंडेंसी के पूरे ट्रांज़िशन क्लोज़र की जांच करता है. इससे यह पक्का होता है कि उन टारगेट में किए गए किसी भी बदलाव को फ़ाइनल नतीजे में दिखाया जाए. साथ ही, ज़रूरत के हिसाब से इंटरमीडिएट को फिर से बनाया जाए.

डिपेंडेंसी की ट्रांज़िटिव प्रकृति से एक आम गलती होती है. कभी-कभी, एक फ़ाइल में मौजूद कोड, किसी इनडायरेक्ट डिपेंडेंसी से मिले कोड का इस्तेमाल कर सकता है. यह डिपेंडेंसी ग्राफ़ में एक ट्रांज़िशनिव, लेकिन डायरेक्ट एज नहीं होता. BUILD फ़ाइल में, इनडायरेक्ट डिपेंडेंसी नहीं दिखती हैं. यह नियम, सेवा देने वाली कंपनी पर सीधे तौर पर निर्भर नहीं करता. इसलिए, बदलावों को ट्रैक करने का कोई तरीका नहीं है. इसकी जानकारी, नीचे दी गई टाइमलाइन में दी गई है:

1. एलान की गई डिपेंडेंसी, असल डिपेंडेंसी से मेल खाती हों

शुरुआत में, सब कुछ ठीक से काम करता है. पैकेज a में मौजूद कोड, पैकेज b में मौजूद कोड का इस्तेमाल करता है. b पैकेज में मौजूद कोड, c पैकेज में मौजूद कोड का इस्तेमाल करता है. इसलिए, a ट्रांज़िट के तौर पर c पर निर्भर करता है.

a/BUILD	b/BUILD
rule( name = "a", srcs = "a.in", deps = "//b:b", )	rule( name = "b", srcs = "b.in", deps = "//c:c", )
a / a.in	b / b.in
import b; b.foo();	import c; function foo() { c.bar(); }

एलान की गई डिपेंडेंसी, असल डिपेंडेंसी से ज़्यादा होती हैं. सब ठीक है.

2. ऐसी डिपेंडेंसी जोड़ना जिसकी जानकारी नहीं दी गई है

जब कोई व्यक्ति a में कोड जोड़ता है, जो c पर सीधे तौर पर असल डिपेंडेंसी बनाता है, लेकिन बिल्ड फ़ाइलa/BUILD में इस बारे में जानकारी नहीं देता है, तो देर से होने वाला खतरा पैदा होता है.

a / a.in
import b; import c; b.foo(); c.garply();

डिक्लेयर्ड डिपेंडेंसी, अब असल डिपेंडेंसी से ज़्यादा नहीं होती हैं. यह ठीक हो सकता है, क्योंकि दो ग्राफ़ के ट्रांज़िटिव क्लोज़िंग बराबर हैं, लेकिन एक समस्या को छिपा देता है: a, c पर असल में, लेकिन तय नहीं की गई डिपेंडेंसी है.

3. डिक्लेयर्ड और असल डिपेंडेंसी ग्राफ़ के बीच अंतर

खतरे का पता तब चलता है, जब कोई व्यक्ति b को इस तरह से रीफ़ैक्ट करता है कि यह c पर निर्भर न रहे, जिससे अनजाने में a की कोई गलती न हुई हो.

	b/BUILD
	rule( name = "b", srcs = "b.in", deps = "//d:d", )
	b / b.in
	import d; function foo() { d.baz(); }

तय किया गया डिपेंडेंसी ग्राफ़, अब असल डिपेंडेंसी का अनुमान से कम है. ऐसा ट्रांज़िट के तौर पर बंद होने के बाद भी किया जाता है. बिल्ड शायद फ़ेल हो सकता है.

इस समस्या को रोका जा सकता था. इसके लिए, यह पक्का करना ज़रूरी था कि दूसरे चरण में a से c तक की असल डिपेंडेंसी, BUILD फ़ाइल में सही तरीके से बताई गई हो.

डिपेंडेंसी के टाइप

ज़्यादातर बिल्ड नियमों में अलग-अलग तरह की सामान्य डिपेंडेंसी तय करने के लिए तीन एट्रिब्यूट होते हैं: srcs, deps, और data. इनके बारे में यहां बताया गया है. ज़्यादा जानकारी के लिए, सभी नियमों के लिए सामान्य एट्रिब्यूट देखें.

कई नियमों में अलग-अलग तरह की डिपेंडेंसी के लिए अतिरिक्त एट्रिब्यूट भी होते हैं, जैसे कि compiler या resources. इस बारे में ज़्यादा जानकारी बिल्ड एनसाइक्लोपीडिया में दी गई है.

srcs डिपेंडेंसी

सोर्स फ़ाइलों को आउटपुट करने वाले नियम या नियमों से सीधे तौर पर इस्तेमाल की जाने वाली फ़ाइलें.

deps डिपेंडेंसी

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

data डिपेंडेंसी

किसी बिल्ड टारगेट को सही तरीके से चलाने के लिए, शायद उसे कुछ डेटा फ़ाइलों की ज़रूरत पड़े. ये डेटा फ़ाइलें सोर्स कोड नहीं हैं: इनसे टारगेट बनाने के तरीके पर कोई असर नहीं पड़ता. उदाहरण के लिए, यूनिट टेस्ट में किसी फ़ंक्शन के आउटपुट की तुलना, फ़ाइल के कॉन्टेंट से की जा सकती है. यूनिट टेस्ट बनाने के लिए, आपको फ़ाइल की ज़रूरत नहीं होती. हालांकि, टेस्ट चलाने के लिए, आपको इसकी ज़रूरत होती है. यही बात उन टूल पर भी लागू होती है जो प्रोग्राम चलाने के दौरान लॉन्च किए जाते हैं.

बिल्ड सिस्टम, एक अलग डायरेक्ट्री में टेस्ट चलाता है. इसमें सिर्फ़ data के तौर पर सूची में शामिल फ़ाइलें उपलब्ध होती हैं. इसलिए, अगर किसी बाइनरी/लाइब्रेरी/टेस्ट को कुछ फ़ाइलों को चलाने की ज़रूरत है, तो data में उनकी जानकारी (या उनमें शामिल एक बिल्ड नियम) बताएं. उदाहरण के लिए:

# I need a config file from a directory named env:
java_binary(
    name = "setenv",
    ...
    data = [":env/default_env.txt"],
)

# I need test data from another directory
sh_test(
    name = "regtest",
    srcs = ["regtest.sh"],
    data = [
        "//data:file1.txt",
        "//data:file2.txt",
        ...
    ],
)

ये फ़ाइलें मिलते-जुलते पाथ path/to/data/file का इस्तेमाल करके उपलब्ध हैं. टेस्ट में, इन फ़ाइलों का रेफ़रंस देने के लिए, टेस्ट की सोर्स डायरेक्ट्री और Workspace के हिसाब से पाथ को जोड़ें. उदाहरण के लिए, ${TEST_SRCDIR}/workspace/path/to/data/file.

डायरेक्ट्री का रेफ़रंस देने के लिए लेबल का इस्तेमाल करना

हमारी BUILD फ़ाइलों को देखते समय, आपको पता चल सकता है कि कुछ data लेबल, डायरेक्ट्री से जुड़े हैं. ये लेबल /. या / पर खत्म होते हैं, जैसे कि इन उदाहरणों में दिए गए लेबल. इन्हें इस्तेमाल नहीं किया जाना चाहिए:

इसका सुझाव नहीं दिया जाता — data = ["//data/regression:unittest/."]

इसका सुझाव नहीं दिया जाता — data = ["testdata/."]

इसका सुझाव नहीं दिया जाता — data = ["testdata/"]

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

हालांकि, ऐसा न करें. बिल्ड सिस्टम को उन फ़ाइलों के पूरे सेट की जानकारी होनी चाहिए जो बिल्ड (या टेस्ट) के इनपुट के तौर पर मौजूद हैं. इससे यह पक्का किया जा सकेगा कि किसी बदलाव के बाद, इंक्रीमेंटल रीबिल्ड (और टेस्ट को फिर से लागू करना) सही तरीके से हो. डायरेक्ट्री के बारे में बताने पर, बिल्ड सिस्टम सिर्फ़ तब रीबिल्ड करता है, जब डायरेक्ट्री में बदलाव होता है (फ़ाइलें जोड़ने या मिटाए जाने की वजह से). हालांकि, अलग-अलग फ़ाइलों में किए गए बदलावों की पहचान नहीं की जा सकती, क्योंकि इन बदलावों से पास की डायरेक्ट्री पर कोई असर नहीं पड़ता. बिल्ड सिस्टम में इनपुट के तौर पर डायरेक्ट्री तय करने के बजाय, आपको उनमें मौजूद फ़ाइलों के सेट की सूची बनानी चाहिए. इसके लिए, साफ़ तौर पर या glob() फ़ंक्शन का इस्तेमाल करें. (glob() को बार-बार इस्तेमाल करने के लिए, ** का इस्तेमाल करें.)

सुझाया गया — data = glob(["testdata/**"])

हालांकि, कुछ मामलों में डायरेक्ट्री लेबल का इस्तेमाल करना ज़रूरी है. उदाहरण के लिए, अगर testdata डायरेक्ट्री में ऐसी फ़ाइलें हैं जिनके नाम लेबल सिंटैक्स के मुताबिक नहीं हैं, तो फ़ाइलों की साफ़ तौर पर गिनती करने या glob() फ़ंक्शन का इस्तेमाल करने पर, अमान्य लेबल की गड़बड़ी का मैसेज दिखता है. इस मामले में, आपको डायरेक्ट्री लेबल का इस्तेमाल करना होगा. हालांकि, ऊपर बताए गए गलत तरीके से फिर से बनाने के जोखिम से सावधान रहें.

अगर आपको डायरेक्ट्री लेबल का इस्तेमाल करना है, तो ध्यान रखें कि आप किसी मिलते-जुलते ../ पाथ वाले पैरंट पैकेज को रेफ़र नहीं कर सकते. इसके बजाय, //data/regression:unittest/. जैसे ऐब्सलूट पाथ का इस्तेमाल करें.

कोई भी बाहरी नियम, जैसे कि टेस्ट, जिसमें कई फ़ाइलों के इस्तेमाल की ज़रूरत होती है, उसके लिए यह साफ़ तौर पर बताया जाना चाहिए कि वह उन सभी पर निर्भर है. BUILD फ़ाइल में फ़ाइलों को एक साथ ग्रुप करने के लिए, filegroup() का इस्तेमाल किया जा सकता है:

filegroup(
        name = 'my_data',
        srcs = glob(['my_unittest_data/*'])
)

इसके बाद, अपने टेस्ट में डेटा डिपेंडेंसी के तौर पर लेबल my_data का रेफ़रंस दिया जा सकता है.