इस पेज पर बताया गया है कि आप अपने कोड पर निर्भरताओं को ट्रेस करने के लिए, Bazel की क्वेरी भाषा का इस्तेमाल कैसे शुरू करें.
भाषा की जानकारी और --output फ़्लैग की जानकारी के लिए, कृपया संदर्भ मैन्युअल, Bazel क्वेरी के बारे में जानकारी
और Bazel cquery रेफ़रंस देखें. आप कमांड लाइन पर bazel help query या bazel help cquery टाइप करके, मदद पा सकते हैं.
छूटे हुए टारगेट जैसी गड़बड़ियों को अनदेखा करते हुए, क्वेरी चलाने के लिए, --keep_going फ़्लैग का इस्तेमाल करें.
नियम की निर्भरता का पता लगाना
//foo की डिपेंडेंसी देखने के लिए, bazel क्वेरी में
deps फ़ंक्शन का इस्तेमाल करें:
$ bazel query "deps(//foo)" //foo:foo //foo:foo-dep ...
यह //foo को बनाने के लिए ज़रूरी सभी टारगेट का सेट है.
दो पैकेज के बीच डिपेंडेंसी चेन ट्रेस करना
//third_party/zlib:zlibonly लाइब्रेरी, //foo के लिए BUILD फ़ाइल में नहीं है. हालांकि, यह सीधे तौर पर नहीं जुड़ी है. हम इस डिपेंडेंसी पाथ का पता कैसे लगा सकते हैं? इससे जुड़े दो काम यहां किए जा सकते हैं:
allpaths और somepath. अगर आपको सिर्फ़ अपने बनाए गए आर्टफ़ैक्ट में मौजूद चीज़ों के बारे में जानना है, तो यह हो सकता है कि आपको --notool_deps के साथ टूल के लिए डिपेंडेंसी छोड़नी पड़े.
सभी डिपेंडेंसी का ग्राफ़ विज़ुअलाइज़ करने के लिए, bazel क्वेरी आउटपुट को
dot कमांड-लाइन टूल की मदद से पाइप करें:
$ bazel query "allpaths(//foo, third_party/...)" --notool_deps --output graph | dot -Tsvg > /tmp/deps.svg
जब कोई डिपेंडेंसी ग्राफ़ बड़ा और जटिल होता है, तो उसे एक पाथ से शुरू करने से मदद मिल सकती है:
$ bazel query "somepath(//foo:foo, third_party/zlib:zlibonly)" //foo:foo //translations/tools:translator //translations/base:base //third_party/py/MySQL:MySQL //third_party/py/MySQL:_MySQL.so //third_party/mysql:mysql //third_party/zlib:zlibonly
अगर आप allpaths के साथ --output graph तय नहीं करते हैं,
तो आपको डिपेंडेंसी ग्राफ़ की फ़्लैटन सूची मिलेगी.
$ bazel query "allpaths(//foo, third_party/...)" ...many errors detected in BUILD files... //foo:foo //translations/tools:translator //translations/tools:aggregator //translations/base:base //tools/pkg:pex //tools/pkg:pex_phase_one //tools/pkg:pex_lib //third_party/python:python_lib //translations/tools:messages //third_party/py/xml:xml //third_party/py/xml:utils/boolean.so //third_party/py/xml:parsers/sgmlop.so //third_party/py/xml:parsers/pyexpat.so //third_party/py/MySQL:MySQL //third_party/py/MySQL:_MySQL.so //third_party/mysql:mysql //third_party/openssl:openssl //third_party/zlib:zlibonly //third_party/zlib:zlibonly_v1_2_3 //third_party/python:headers //third_party/openssl:crypto
इसके अलावा: इंडिपेंडेंट डिपेंडेंसी
//foo के लिए बनी BUILD फ़ाइल कभी भी
//translations/tools:aggregator का रेफ़रंस नहीं देती. इसलिए, प्रत्यक्ष निर्भरता कहां है?
कुछ नियमों में, अन्य लाइब्रेरी या टूल पर निर्भर करना शामिल है.
उदाहरण के लिए, genproto नियम बनाने से पहले, आपको प्रोटोकॉल
कंपाइलर बनाना होगा. इसलिए, हर genproto नियम, प्रोटोकॉल कंपाइलर पर इंडिपेंडेंट डिपेंडेंसी देता है. ये डिपेंडेंसी बिल्ड फ़ाइल में नहीं हैं,
लेकिन बिल्ड टूल ने इन्हें जोड़ा है. इंप्लिसिट डिपेंडेंसी के पूरे सेट को
फ़िलहाल रिकॉर्ड नहीं किया गया है. --noimplicit_deps का इस्तेमाल करके, अपनी क्वेरी के नतीजों से ऐसे फ़िल्टर को फ़िल्टर किया जा सकता है. कुकी के लिए, इसमें समाधान की गई टूलटिप शामिल होंगी.
रिवर्स डिपेंडेंसी
हो सकता है कि आप उन टारगेट के बारे में जानना चाहें जो कुछ टारगेट पर निर्भर करते हैं. उदाहरण के लिए,
अगर आप कुछ कोड को बदलने वाले हैं, तो हो सकता है कि आप यह जानना चाहें कि आप कौन से अन्य
कोड को तोड़ने वाले हैं. आप rdeps(u, x) के लक्ष्यों की रिवर्स डिपेंडेंसी के लिए, x का इस्तेमाल u में कर सकते हैं.
Bazel की Sky Query,
allrdeps फ़ंक्शन के साथ काम करती है. इसकी मदद से, आपके बताए गए ब्रह्मांड में रिवर्स डिपेंडेंसी के बारे में क्वेरी की जा सकती है.
अन्य इस्तेमाल
bazel query का इस्तेमाल, डिपेंडेंसी के कई संबंधों का विश्लेषण करने के लिए किया जा सकता है.
क्या मौजूद है ...
foo के नीचे कौनसे पैकेज मौजूद हैं?
bazel query 'foo/...' --output package
foo पैकेज में कौनसे नियम तय किए गए हैं?
bazel query 'kind(rule, foo:*)' --output label_kind
foo पैकेज में मौजूद नियम के मुताबिक कौनसी फ़ाइलें जनरेट होती हैं?
bazel query 'kind("generated file", //foo:*)'
स्टारलार्क मैक्रो foo के ज़रिए कौनसे टारगेट जनरेट किए जाते हैं?
bazel query 'attr(generator_function, foo, //path/to/search/...)'
//foo को बनाने के लिए, BUILD फ़ाइलों का सेट क्या है?
bazel query 'buildfiles(deps(//foo))' | cut -f1 -d:
test_suite के तहत, अलग-अलग जांच कौनसी हैं?
bazel query 'tests(//foo:smoke_tests)'
उनमें से कौन सी C++ परीक्षण हैं?
bazel query 'kind(cc_.*, tests(//foo:smoke_tests))'
उनमें से कौनसी छोटी हैं? मध्यम? बड़ा?
bazel query 'attr(size, small, tests(//foo:smoke_tests))' bazel query 'attr(size, medium, tests(//foo:smoke_tests))' bazel query 'attr(size, large, tests(//foo:smoke_tests))'
foo के नीचे मौजूद ऐसे टेस्ट क्या हैं जो किसी पैटर्न से मेल खाते हैं?
bazel query 'filter("pa?t", kind(".*_test rule", //foo/...))'
पैटर्न एक रेगुलर एक्सप्रेशन होता है. यह नियम के पूरे नाम पर लागू होता है. यह ऐसा ही है
bazel query 'kind(".*_test rule", //foo/...)' | grep -E 'pa?t'
किस पैकेज में फ़ाइल path/to/file/bar.java है?
bazel query path/to/file/bar.java --output=package
path/to/file/bar.java? के लिए बिल्ड लेबल क्या है
bazel query path/to/file/bar.java
कौनसे नियम टारगेट में path/to/file/bar.java फ़ाइल शामिल है?
fullname=$(bazel query path/to/file/bar.java)
bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)"
कौनसी पैकेज डिपेंडेंसी मौजूद हैं ...
foo किस पैकेज पर निर्भर है? (foo बनाने के लिए मुझे क्या देखना होगा)
bazel query 'buildfiles(deps(//foo:foo))' --output package
foo/contrib को छोड़कर, foo ट्री किन पैकेज पर निर्भर है?
bazel query 'deps(foo/... except foo/contrib/...)' --output package
नियम पर कौनसी डिपेंडेंसी लागू होती हैं ...
बार किन जेनप्रोटो नियमों पर निर्भर है?
bazel query 'kind(genproto, deps(bar/...))'
कुछ JNI (C++) लाइब्रेरी की परिभाषा देखें. यह सर्वलेट ट्री में, Java बाइनरी नियम के हिसाब से, हमेशा के लिए निर्भर करती है.
bazel query 'some(kind(cc_.*library, deps(kind(java_binary, //java/com/example/frontend/...))))' --output location
...अब उन सभी Java बाइनरी की परिभाषाएं देखें जो उन पर निर्भर हैं
bazel query 'let jbs = kind(java_binary, //java/com/example/frontend/...) in
let cls = kind(cc_.*library, deps($jbs)) in
$jbs intersect allpaths($jbs, $cls)'
कौनसी फ़ाइल डिपेंडेंसी मौजूद हैं ...
foo बनाने के लिए आवश्यक Java स्रोत फ़ाइलों का पूरा सेट क्या है?
सोर्स फ़ाइलें:
bazel query 'kind("source file", deps(//path/to/target/foo/...))' | grep java$
जनरेट की गई फ़ाइलें:
bazel query 'kind("generated file", deps(//path/to/target/foo/...))' | grep java$
QUX की जांच करने के लिए, Java सोर्स फ़ाइलों के पूरे सेट की ज़रूरत क्या है?
सोर्स फ़ाइलें:
bazel query 'kind("source file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$
जनरेट की गई फ़ाइलें:
bazel query 'kind("generated file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$
X और Y के बीच डिपेंडेंसी में क्या अंतर है ...
//foo किस तरह के टारगेट का इस्तेमाल करता है, जो //foo:foolib के मुताबिक नहीं है?
bazel query 'deps(//foo) except deps(//foo:foolib)'
foo की कौनसी C++ लाइब्रेरी इस बात पर निर्भर करती है कि //foo प्रोडक्शन बाइनरी किस पर निर्भर नहीं करती है?
bazel query 'kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo))'
यह डिपेंडेंसी क्यों ज़रूरी है ...
bar, groups2 पर निर्भर क्यों है?
bazel query 'somepath(bar/...,groups2/...:*)'
जब आपको इस क्वेरी के नतीजे मिलते हैं, तो आपको अक्सर पता चल जाएगा कि सिर्फ़ एक टारगेट, bar की उम्मीद के मुताबिक या बहुत ज़्यादा निर्भर करता है. इसके बाद, क्वेरी को और भी बेहतर बनाया जा सकता है, ताकि:
मुझे docker/updater:updater_systest से py_test (cc_library) तक का वह रास्ता दिखाएं जो इस पर निर्भर करता है:
bazel query 'let cc = kind(cc_library, deps(docker/updater:updater_systest)) in somepath(docker/updater:updater_systest, $cc)'
लाइब्रेरी //photos/frontend:lib एक ही लाइब्रेरी //third_party/jpeglib और //third_party/jpeg के दो वैरिएंट पर निर्भर क्यों है?
यह क्वेरी इस पर निर्भर करती है: "मुझे //photos/frontend:lib का सबग्राफ़ दिखाएं, जो
दोनों लाइब्रेरी पर निर्भर करता है". टोपिकल क्रम में दिखाए जाने पर, नतीजे का आखिरी
एलिमेंट सबसे ज़्यादा दोषी होता है.
bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib)
intersect
allpaths(//photos/frontend:lib, //third_party/jpeg)'
//photos/frontend:lib
//photos/frontend:lib_impl
//photos/frontend:lib_dispatcher
//photos/frontend:icons
//photos/frontend/modules/gadgets:gadget_icon
//photos/thumbnailer:thumbnail_lib
//third_party/jpeg/img:renderer
यह इन बातों पर निर्भर करता है ...
बार के कौनसे नियम Y पर निर्भर करते हैं?
bazel query 'bar/... intersect allpaths(bar/..., Y)'
टी के पैकेज में क्या टारगेट सीधे T पर निर्भर करते हैं?
bazel query 'same_pkg_direct_rdeps(T)'
मैं डिपेंडेंसी को कैसे तोड़ूं ...
bar को अब X पर निर्भर न करने के लिए, मुझे डिपेंडेंसी वाले कौनसे पाथ का इस्तेमाल करना होगा?
ग्राफ़ को किसी svg फ़ाइल में डालने के लिए:
bazel query 'allpaths(bar/...,X)' --output graph | dot -Tsvg > /tmp/dep.svg
अन्य सुविधाएं
//foo-tests बिल्ड में कितने सिलसिलेवार कदम हैं?
माफ़ करें, क्वेरी की भाषा में फ़िलहाल x से y तक का सबसे लंबा पाथ नहीं दिया जा सकता, लेकिन यह शुरुआत की जगह से (या a) सबसे दूर का नोड ढूंढ सकता है. इसके अलावा, यह आपको x से हर उस सबसे लंबे पाथ की लंबाई दिखा सकता है जिस पर यह निर्भर करता है. maxrank का इस्तेमाल करें:
bazel query 'deps(//foo-tests)' --output maxrank | tail -1 85 //third_party/zlib:zutil.c
नतीजा यह बताता है कि 85 वर्णों के ऐसे पाथ मौजूद हैं जो इस बिल्ड में क्रम में लगाए जाने चाहिए.