क्वेरी गाइड

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

इस पेज में बताया गया है कि अपने कोड पर डिपेंडेंसी को ट्रेस करने के लिए, Basel की क्वेरी लैंग्वेज का इस्तेमाल कैसे करना है.

भाषा की जानकारी और --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 की मदद से टूल की डिपेंडेंसी को भी बाहर रखा जा सकता है.

सभी डिपेंडेंसी का ग्राफ़ देखने के लिए, dot कमांड-लाइन टूल के ज़रिए, bazel क्वेरी के आउटपुट को पाइप करें:

$ 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 का इस्तेमाल करके, अपनी क्वेरी के नतीजों से इन रिपोर्ट को फ़िल्टर किया जा सकता है. cquery के लिए, इसमें हल किए गए टूलचेन शामिल होंगे.

रिवर्स डिपेंडेंसी

ऐसा हो सकता है कि आप किसी टारगेट पर आधारित टारगेट के सेट के बारे में जानना चाहें. उदाहरण के लिए, अगर आपको कोई कोड बदलना है, तो आपको यह जानना होगा कि इससे कौनसा दूसरा कोड काम करना बंद कर देगा. rdeps(u, x) का इस्तेमाल करके, u के ट्रांज़िशन क्लोज़र में x के टारगेट की रिवर्स डिपेंडेंसी ढूंढी जा सकती है.

बेज़ल की स्काई क्वेरी, 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:*)'

Starlark मैक्रो 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 ट्री, foo/contrib को छोड़कर किन पैकेज पर निर्भर करता है?

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 (a 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 के पैकेज में, कौनसे टारगेट सीधे 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 से हर उस y तक के सबसे लंबे पाथ की लंबाई दिखा सकती है जिस पर यह निर्भर करता है. maxrank का इस्तेमाल करें:

bazel query 'deps(//foo-tests)' --output maxrank | tail -1
85 //third_party/zlib:zutil.c

नतीजे से पता चलता है कि 85 वर्णों वाले ऐसे पाथ मौजूद हैं जो इस बिल्ड में क्रम से होने चाहिए.