BazelCon 2024 का रजिस्ट्रेशन और सीएफ़पी अब शुरू हो गया है!
रिलीज़ होने वाले ठीक से काम करने वाले दस्तावेज़ों के लिए, कृपया "वर्शन दस्तावेज़" ड्रॉप-डाउन का इस्तेमाल करें. डिफ़ॉल्ट व्यू, head पर सबसे नए वर्शन को दिखाता है.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

कॉन्फ़िगर करने लायक क्वेरी (cquery)

समस्या की शिकायत करें सोर्स देखें ठीक

cquery, query का एक वैरिएंट है. यह बिल्ड ग्राफ़ पर select() को सही तरीके से हैंडल करता है और विकल्पों के इफ़ेक्ट को बिल्ड करता है.

ऐसा करने के लिए, Basel के विश्लेषण के चरण के नतीजों को ध्यान में रखा जाता है. इस फ़ेज़ में, इन इफ़ेक्ट को इंटिग्रेट किया जाता है. वहीं, query, विकल्पों के आकलन से पहले, बैजल के लोड होने के चरण के नतीजों पर काम करता है.

उदाहरण के लिए:

$ cat > tree/BUILD <<EOF
sh_library(
    name = "ash",
    deps = select({
        ":excelsior": [":manna-ash"],
        ":americana": [":white-ash"],
        "//conditions:default": [":common-ash"],
    }),
)
sh_library(name = "manna-ash")
sh_library(name = "white-ash")
sh_library(name = "common-ash")
config_setting(
    name = "excelsior",
    values = {"define": "species=excelsior"},
)
config_setting(
    name = "americana",
    values = {"define": "species=americana"},
)
EOF

# Traditional query: query doesn't know which select() branch you will choose,
# so it conservatively lists all of possible choices, including all used config_settings.
$ bazel query "deps(//tree:ash)" --noimplicit_deps
//tree:americana
//tree:ash
//tree:common-ash
//tree:excelsior
//tree:manna-ash
//tree:white-ash

# cquery: cquery lets you set build options at the command line and chooses
# the exact dependencies that implies (and also the config_setting targets).
$ bazel cquery "deps(//tree:ash)" --define species=excelsior --noimplicit_deps
//tree:ash (9f87702)
//tree:manna-ash (9f87702)
//tree:americana (9f87702)
//tree:excelsior (9f87702)

हर नतीजे में, उस कॉन्फ़िगरेशन का एक यूनीक आइडेंटिफ़ायर (9f87702) शामिल होता है जिससे टारगेट बनाया गया है.

cquery, कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर चलता है. इसमें, बिल्ड ऐक्शन या test_suite के ऐक्सेस जैसे आर्टफ़ैक्ट की अहम जानकारी नहीं होती, क्योंकि ये कॉन्फ़िगर किए गए टारगेट नहीं होते. पहली ऐसेट के लिए, aquery देखें.

बेसिक सिंटैक्स

एक सामान्य cquery कॉल ऐसा दिखाई देता है:

bazel cquery "function(//target)"

क्वेरी एक्सप्रेशन "function(//target)" में ये शामिल हैं:

function(...) फ़ंक्शन को टारगेट पर चलाया जाता है. cquery, query के ज़्यादातर फ़ंक्शन के साथ-साथ कुछ नए फ़ंक्शन के साथ काम करता है.
//target फ़ंक्शन को दिया गया एक्सप्रेशन है. इस उदाहरण में, एक्सप्रेशन एक आसान टारगेट है. हालांकि, क्वेरी लैंग्वेज में फ़ंक्शन को नेस्ट करने की भी अनुमति है. उदाहरणों के लिए क्वेरी गाइड देखें.

cquery को लोड करने और विश्लेषण के चरणों को पूरा करने के लिए टारगेट की ज़रूरत होती है. जब तक अलग से न बताया जाए, cquery, क्वेरी एक्सप्रेशन में शामिल टारगेट को पार्स करता है. टॉप-लेवल के बिल्ड टारगेट की डिपेंडेंसी के बारे में क्वेरी करने के लिए, --universe_scope पर जाएं.

कॉन्फ़िगरेशन

लाइन:

//tree:ash (9f87702)

इसका मतलब है कि //tree:ash को 9f87702 आईडी वाले कॉन्फ़िगरेशन में बनाया गया है. ज़्यादातर टारगेट के लिए, यह कॉन्फ़िगरेशन को तय करने वाले बिल्ड विकल्प की वैल्यू का ओपेक हैश है.

कॉन्फ़िगरेशन का पूरा कॉन्टेंट देखने के लिए, इसे चलाएं:

$ bazel config 9f87702

9f87702 पूरे आईडी का प्रीफ़िक्स है. ऐसा इसलिए होता है, क्योंकि पूरा आईडी SHA-256 हैश होते हैं, जो लंबे होते हैं और जिन्हें फ़ॉलो करना मुश्किल होता है. cquery, पूरे आईडी के किसी भी मान्य प्रीफ़िक्स को समझता है. यह Git शॉर्ट हैश की तरह ही है. पूरे आईडी देखने के लिए, $ bazel config चलाएं.

टारगेट पैटर्न का इवैलुएशन

//foo का cquery का मतलब query से अलग होता है. इसकी वजह यह है कि cquery, कॉन्फ़िगर किए गए टारगेट का आकलन करता है और बिल्ड ग्राफ़ में //foo के कॉन्फ़िगर किए गए कई वर्शन हो सकते हैं.

cquery के लिए, क्वेरी एक्सप्रेशन में मौजूद टारगेट पैटर्न, कॉन्फ़िगर किए गए हर ऐसे टारगेट की जांच करता है जिसके लेबल का मिलान उस पैटर्न से होता है. आउटपुट तय होता है, लेकिन cquery क्वेरी को क्रम में लगाने के मुख्य अनुबंध के अलावा, किसी और तरह के ऑर्डर की गारंटी नहीं देता.

यह क्वेरी एक्सप्रेशन के लिए, query की तुलना में ज़्यादा बेहतर नतीजे देता है. उदाहरण के लिए, नीचे दी गई स्थितियों में एक से ज़्यादा नतीजे मिल सकते हैं:

# Analyzes //foo in the target configuration, but also analyzes
# //genrule_with_foo_as_tool which depends on an exec-configured
# //foo. So there are two configured target instances of //foo in
# the build graph.
$ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
//foo (9f87702)
//foo (exec)

अगर आपको साफ़ तौर पर यह बताना है कि किस इंस्टेंस पर क्वेरी करनी है, तो config फ़ंक्शन का इस्तेमाल करें.

टारगेट पैटर्न के बारे में ज़्यादा जानकारी के लिए, query के टारगेट पैटर्न से जुड़े दस्तावेज़ देखें.

फ़ंक्शन

query के साथ काम करने वाले फ़ंक्शन के सेट में से cquery, visible, siblings, buildfiles, और tests को छोड़कर सभी के साथ काम करता है.

cquery में ये नए फ़ंक्शन भी पेश किए गए हैं:

कॉन्फ़िगरेशन

expr ::= config(expr, word)

config ऑपरेटर, दूसरे तर्क के बताए गए पहले आर्ग्युमेंट और कॉन्फ़िगरेशन से दिखाए गए लेबल के लिए, कॉन्फ़िगर किए गए टारगेट को ढूंढने की कोशिश करता है.

दूसरे आर्ग्युमेंट के लिए मान्य वैल्यू, null या कस्टम कॉन्फ़िगरेशन हैश हैं. हैश को $ bazel config या पिछले cquery के आउटपुट से वापस लाया जा सकता है.

उदाहरण:

$ bazel cquery "config(//bar, 3732cc8)" --universe_scope=//foo

$ bazel cquery "deps(//foo)"
//bar (exec)
//baz (exec)

$ bazel cquery "config(//baz, 3732cc8)"

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

विकल्प

बिल्ड के विकल्प

cquery, सामान्य बेज़ल बिल्ड पर चलता है और इसलिए बिल्ड के दौरान उपलब्ध विकल्प के सेट को इनहेरिट करता है.

cquery विकल्पों का इस्तेमाल करना

`--universe_scope` (कॉमा लगाकर अलग की गई सूची)

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

# x/BUILD
genrule(
     name = "my_gen",
     srcs = ["x.in"],
     outs = ["x.cc"],
     cmd = "$(locations :tool) $< >$@",
     tools = [":tool"],
)
cc_binary(
    name = "tool",
    srcs = ["tool.cpp"],
)

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

क्वेरी	टारगेट बनाया गया	आउटपुट
बेज़ल Cquery "//x:tool"	//x:tool	//x:tool(targetconfig)
बेज़ल Cquery "//x:tool" --universe_scope="//x:my_gen"	//x:my_gen	//x:tool(execconfig)

अगर यह फ़्लैग सेट है, तो इसका कॉन्टेंट बनाया जाता है. अगर यह नीति सेट नहीं है, तो क्वेरी एक्सप्रेशन में दिए गए सभी टारगेट बनाए जाते हैं. बनाए गए टारगेट के ट्रांज़िटिव क्लोज़िंग का इस्तेमाल, क्वेरी की यूनिवर्स के तौर पर किया जाता है. किसी भी स्थिति में, बनाए जाने वाले टारगेट टॉप लेवल पर बनाए जाने लायक होने चाहिए (यानी, टॉप लेवल विकल्पों के साथ काम कर सकते हैं). cquery फ़ंक्शन से इन टॉप-लेवल टारगेट को अस्थायी तौर पर बंद करने का नतीजा मिलता है.

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

`--implicit_deps` (बूलियन, डिफ़ॉल्ट=सही)

इस फ़्लैग को 'गलत है' पर सेट करने से, ऐसे सभी नतीजे फ़िल्टर हो जाते हैं जो BUILD फ़ाइल में साफ़ तौर पर सेट नहीं किए गए हैं और इसके बजाय Basel ने कहीं और सेट किए हैं. इसमें रिज़ॉल्व किए जा चुके टूलचेन को फ़िल्टर करना भी शामिल है.

`--tool_deps` (बूलियन, डिफ़ॉल्ट=सही)

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

`--include_aspects` (बूलियन, डिफ़ॉल्ट=सही)

आसपेक्ट की मदद से जोड़ी गई डिपेंडेंसी शामिल करें.

अगर यह फ़्लैग बंद है, तो cquery somepath(X, Y) और cquery deps(X) | grep 'Y', Y को छोड़ देते हैं. ऐसा तब होता है, जब X सिर्फ़ किसी पहलू से जुड़ा हो.

आउटपुट फ़ॉर्मैट

डिफ़ॉल्ट रूप से, cquery के आउटपुट से लेबल और कॉन्फ़िगरेशन पेयर की डिपेंडेंसी के हिसाब से क्रम वाली सूची बनती है. नतीजे दिखाने के और भी विकल्प हैं.

ट्रांज़िशन

--transitions=lite
--transitions=full

कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल, टॉप लेवल टारगेट के मुकाबले अलग-अलग कॉन्फ़िगरेशन में टॉप लेवल टारगेट के नीचे के टारगेट बनाने के लिए किया जाता है.

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

यह आउटपुट फ़ॉर्मैट, --transitions फ़्लैग से ट्रिगर होता है. डिफ़ॉल्ट रूप से, यह फ़ॉर्मैट NONE पर सेट होता है. इसे FULL या LITE मोड पर सेट किया जा सकता है. FULL मोड, नियम की क्लास के ट्रांज़िशन और एट्रिब्यूट के ट्रांज़िशन के बारे में जानकारी देता है. इसमें ट्रांज़िशन से पहले और बाद के विकल्पों में अंतर की पूरी जानकारी भी शामिल होती है. LITE मोड अलग-अलग विकल्पों के बिना वही जानकारी दिखाता है.

प्रोटोकॉल मैसेज का आउटपुट

--output=proto

इस विकल्प से बनने वाले टारगेट बाइनरी प्रोटोकॉल बफ़र फ़ॉर्म में प्रिंट होते हैं. प्रोटोकॉल बफ़र की परिभाषा src/main/protobuf/analysis_v2.proto पर देखी जा सकती है.

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

--[no]proto:include_configurations

डिफ़ॉल्ट रूप से, cquery के नतीजों में कॉन्फ़िगरेशन की जानकारी, कॉन्फ़िगर किए गए हर टारगेट के हिस्से के तौर पर दिखती है. अगर आपको इस जानकारी को छोड़कर, क्वेरी के प्रोटो आउटपुट की तरह फ़ॉर्मैट किया गया प्रोटो आउटपुट पाना है, तो इस फ़्लैग को'गलत' पर सेट करें.

प्रोटो आउटपुट से जुड़े ज़्यादा विकल्पों के लिए, क्वेरी का प्रोटो आउटपुट दस्तावेज़ देखें.

ग्राफ़ का आउटपुट

--output=graph

यह विकल्प आउटपुट को ग्राफ़विज़ के साथ काम करने वाली .dot फ़ाइल के रूप में जनरेट करता है. ज़्यादा जानकारी के लिए, query का ग्राफ़ आउटपुट दस्तावेज़ देखें. cquery --graph:node_limit और --graph:factored के साथ भी काम करता है.

फ़ाइल आउटपुट

--output=files

इस विकल्प की मदद से, हर टारगेट के हिसाब से बनाई गई आउटपुट फ़ाइलों की सूची प्रिंट की जाती है. क्वेरी से मैच करने वाली उन फ़ाइलों की तरह ही यह सुविधा मिलती है जो bazel build को शुरू करने के आखिर में प्रिंट की गई सूची की तरह होती हैं. आउटपुट में सिर्फ़ वे फ़ाइलें शामिल होती हैं जिनका विज्ञापन अनुरोध किए गए आउटपुट ग्रुप में दिखाया गया है. इन फ़ाइलों को --output_groups फ़्लैग के आधार पर तय किया जाता है. इसमें स्रोत फ़ाइलें शामिल होती हैं.

इस आउटपुट फ़ॉर्मैट से निकलने वाले सभी पाथ, एक्ज़िक्यूट के हिसाब से होते हैं. इस फ़ॉर्मैट को bazel info execution_root से हासिल किया जा सकता है. अगर bazel-out सुविधा सिमलिंक मौजूद है, तो डेटा स्टोर करने की मुख्य जगह में फ़ाइलों के पाथ भी फ़ाइल फ़ोल्डर डायरेक्ट्री के हिसाब से रिज़ॉल्व हो जाते हैं.

Starlark का इस्तेमाल करके आउटपुट फ़ॉर्मैट तय करना

--output=starlark

यह आउटपुट फ़ॉर्मैट, क्वेरी के नतीजे में कॉन्फ़िगर किए गए हर टारगेट के लिए Starlark फ़ंक्शन को कॉल करता है. साथ ही, कॉल से मिलने वाली वैल्यू को प्रिंट करता है. --starlark:file फ़्लैग, उस Starlark फ़ाइल की जगह के बारे में बताता है जो एक ही पैरामीटर target वाले format नाम के फ़ंक्शन के बारे में बताती है. क्वेरी के नतीजे में मौजूद हर टारगेट के लिए इस फ़ंक्शन को कॉल किया जाता है. इसके अलावा, आपकी सुविधा के लिए, def format(target): return expr के तौर पर बताए गए फ़ंक्शन का मुख्य हिस्सा बताने के लिए, --starlark:expr फ़्लैग का इस्तेमाल किया जा सकता है.

'cquery' स्टारलार्क बोली

cquery Starlark एनवायरमेंट BUILD या .bzl फ़ाइल से अलग है. इसमें सभी मुख्य Starlark बिल्ट-इन कॉन्सटेंट और फ़ंक्शन के साथ-साथ नीचे बताई गई cquery से जुड़ी कुछ खास बातें शामिल हैं. हालांकि, (उदाहरण के लिए) glob, native या rule शामिल नहीं हैं. साथ ही, यह लोड स्टेटमेंट के साथ काम नहीं करती.

build_options(target)

build_options(target) ऐसा मैप दिखाता है जिसकी कुंजियां विकल्प के आइडेंटिफ़ायर हैं (कॉन्फ़िगरेशन देखें) और जिनकी वैल्यू Starlark की वैल्यू हैं. उन विकल्पों का निर्माण करें जिनके मान कानूनी स्टारलार्क मान नहीं हैं इस मैप से हटा दिए गए हैं.

अगर टारगेट कोई इनपुट फ़ाइल है, तो build_options(target) कोई नहीं दिखाता है, क्योंकि इनपुट फ़ाइल के टारगेट में शून्य कॉन्फ़िगरेशन होता है.

सेवा देने वाली कंपनियां(टारगेट)

providers(target) ऐसा मैप दिखाता है जिसकी कुंजियां सेवा देने वालों के नाम हैं (उदाहरण के लिए, "DefaultInfo") और जिनकी वैल्यू Starlark की वैल्यू हैं. सेवा देने वाली ऐसी कंपनियां जिनकी वैल्यू, Starlark की कानूनी वैल्यू नहीं हैं उन्हें इस मैप से नहीं हटाया गया है.

उदाहरण

//foo से बनाई गई सभी फ़ाइलों के आधार नामों की, स्पेस से अलग की गई सूची प्रिंट करें:

  bazel cquery //foo --output=starlark \
    --starlark:expr="' '.join([f.basename for f in target.files.to_list()])"

//bar और इसके सबपैकेज में नियम टारगेट के मुताबिक बनाई गई सभी फ़ाइलों के पाथ की सूची, स्पेस से अलग करके बनाई गई हो:

  bazel cquery 'kind(rule, //bar/...)' --output=starlark \
    --starlark:expr="' '.join([f.path for f in target.files.to_list()])"

//foo ने जो भी काम किए हैं उनकी याददाश्त बढ़ाने वाली सूची प्रिंट करें.

  bazel cquery //foo --output=starlark \
    --starlark:expr="[a.mnemonic for a in target.actions]"

cc_library //baz ने जो कंपाइलेशन आउटपुट रजिस्टर किए हैं उनकी सूची प्रिंट करें.

  bazel cquery //baz --output=starlark \
    --starlark:expr="[f.path for f in target.output_groups.compilation_outputs.to_list()]"

//foo बनाते समय, कमांड लाइन विकल्प --javacopt की वैल्यू प्रिंट करें.

  bazel cquery //foo --output=starlark \
    --starlark:expr="build_options(target)['//command_line_option:javacopt']"

हर टारगेट का लेबल सिर्फ़ एक आउटपुट के साथ प्रिंट करें. इस उदाहरण में, किसी फ़ाइल में बताए गए Starlark फ़ंक्शन का इस्तेमाल किया गया है.

  $ cat example.cquery

  def has_one_output(target):
    return len(target.files.to_list()) == 1

  def format(target):
    if has_one_output(target):
      return target.label
    else:
      return ""

  $ bazel cquery //baz --output=starlark --starlark:file=example.cquery

हर टारगेट का लेबल प्रिंट करें जो पूरी तरह से Python 3 है. इस उदाहरण में, किसी फ़ाइल में बताए गए Starlark फ़ंक्शन का इस्तेमाल किया गया है.

  $ cat example.cquery

  def format(target):
    p = providers(target)
    py_info = p.get("PyInfo")
    if py_info and py_info.has_py3_only_sources:
      return target.label
    else:
      return ""

  $ bazel cquery //baz --output=starlark --starlark:file=example.cquery

उपयोगकर्ता की ओर से तय की गई कंपनी से वैल्यू निकालें.

  $ cat some_package/my_rule.bzl

  MyRuleInfo = provider(fields={"color": "the name of a color"})

  def _my_rule_impl(ctx):
      ...
      return [MyRuleInfo(color="red")]

  my_rule = rule(
      implementation = _my_rule_impl,
      attrs = {...},
  )

  $ cat example.cquery

  def format(target):
    p = providers(target)
    my_rule_info = p.get("//some_package:my_rule.bzl%MyRuleInfo'")
    if my_rule_info:
      return my_rule_info.color
    return ""

  $ bazel cquery //baz --output=starlark --starlark:file=example.cquery

cquery बनाम क्वेरी

cquery और query एक-दूसरे की मदद करते हैं और अलग-अलग विषयों में महारत हासिल करते हैं. अपने लिए सही विकल्प चुनने के लिए, यहां दी गई बातों को ध्यान में रखें:

cquery आपके बनाए गए ग्राफ़ को मॉडल करने के लिए, खास select() ब्रांच को फ़ॉलो करता है. query को यह नहीं पता होता कि बिल्ड किस ब्रांच को चुनता है. इसलिए, सभी ब्रांच को शामिल करने से यह पता नहीं चलता है कि बिल्ड कितना सही है.
query की तुलना में, cquery कितना सटीक है, इसके लिए ज़्यादा ग्राफ़ बनाना ज़रूरी है. खास तौर पर, cquery कॉन्फ़िगर किए गए टारगेट का आकलन करता है, जबकि query सिर्फ़ टारगेट का आकलन करता है. इसमें ज़्यादा समय लगता है और यह ज़्यादा स्टोरेज का इस्तेमाल करता है.
क्वेरी की भाषा के बारे में cquery में बताया गया है कि यह साफ़ तौर पर समझ आता है और ऐसी समझ से परे होता है कि query इसका इस्तेमाल नहीं करता. उदाहरण के लिए, अगर "//foo" दो कॉन्फ़िगरेशन में मौजूद है, तो cquery "deps(//foo)" को किस कॉन्फ़िगरेशन का इस्तेमाल करना चाहिए? इसमें config फ़ंक्शन आपकी मदद कर सकता है.
नए टूल के तौर पर, cquery इस्तेमाल के कुछ मामलों में काम नहीं करता है. ज़्यादा जानकारी के लिए, ऐसी समस्याएं जिनके बारे में हमें पता है देखें.

पहले से मालूम समस्याएं

cquery "बिल्ड" किए जाने वाले सभी टारगेट का कॉन्फ़िगरेशन एक जैसा होना चाहिए.

क्वेरी का आकलन करने से पहले, cquery उस पॉइंट से ठीक पहले बिल्ड अप ट्रिगर करता है जहां बिल्ड ऐक्शन लागू होंगे. "बिल्ड" इन टारगेट को डिफ़ॉल्ट रूप से, क्वेरी एक्सप्रेशन में दिखने वाले सभी लेबल में से चुना जाता है. इसे --universe_scope से बदला जा सकता है. इनका कॉन्फ़िगरेशन एक जैसा होना चाहिए.

हालांकि, ये आम तौर पर टॉप-लेवल के "टारगेट" कॉन्फ़िगरेशन को शेयर करते हैं, लेकिन नियम इनकमिंग एज ट्रांज़िशन की मदद से अपना खुद का कॉन्फ़िगरेशन बदल सकते हैं. यहां cquery की शॉर्ट वीडियो कैटगरी कम हो जाती है.

समाधान: अगर मुमकिन हो, तो --universe_scope को ज़्यादा सख्त स्कोप पर सेट करें. उदाहरण के लिए:

# This command attempts to build the transitive closures of both //foo and
# //bar. //bar uses an incoming edge transition to change its --cpu flag.
$ bazel cquery 'somepath(//foo, //bar)'
ERROR: Error doing post analysis query: Top-level targets //foo and //bar
have different configurations (top-level targets with different
configurations is not supported)

# This command only builds the transitive closure of //foo, under which
# //bar should exist in the correct configuration.
$ bazel cquery 'somepath(//foo, //bar)' --universe_scope=//foo

--output=xml के लिए कोई सहायता नहीं है.

नॉन-डिटरमिनिस्टिक आउटपुट.

cquery, पिछले निर्देशों से बिल्ड ग्राफ़ को अपने-आप वाइप नहीं करता है. इस वजह से, इसमें पिछली क्वेरी से नतीजे लिए जाते हैं. उदाहरण के लिए, genrule अपने tools एट्रिब्यूट पर एक exec ट्रांज़िशन लागू करता है. इसका मतलब है कि यह अपने टूल को एक्ज़िक कॉन्फ़िगरेशन में कॉन्फ़िगर करता है.

इस ट्रांज़िशन का असर अब भी देखा जा सकता है.

$ cat > foo/BUILD <<<EOF
genrule(
    name = "my_gen",
    srcs = ["x.in"],
    outs = ["x.cc"],
    cmd = "$(locations :tool) $< >$@",
    tools = [":tool"],
)
cc_library(
    name = "tool",
)
EOF

    $ bazel cquery "//foo:tool"
tool(target_config)

    $ bazel cquery "deps(//foo:my_gen)"
my_gen (target_config)
tool (exec_config)
...

    $ bazel cquery "//foo:tool"
tool(exec_config)

समाधान: कॉन्फ़िगर किए गए टारगेट का फिर से विश्लेषण करने के लिए, किसी भी स्टार्टअप विकल्प को बदलें. उदाहरण के लिए, अपने बिल्ड कमांड में --test_arg=<whatever> जोड़ें.

समस्या हल करना

बार-बार होने वाले टारगेट पैटर्न (`/...`)

अगर आपको:

$ bazel cquery --universe_scope=//foo:app "somepath(//foo:app, //foo/...)"
ERROR: Error doing post analysis query: Evaluation failed: Unable to load package '[foo]'
because package is not in scope. Check that all target patterns in query expression are within the
--universe_scope of this query.

इससे यह गलत पता चलता है कि पैकेज //foo दायरे में नहीं है, हालांकि --universe_scope=//foo:app में यह शामिल है. ऐसा cquery में डिज़ाइन की सीमाओं की वजह से होता है. वैकल्पिक हल के तौर पर, //foo/... को यूनिवर्स के दायरे में साफ़ तौर पर शामिल करें:

$ bazel cquery --universe_scope=//foo:app,//foo/... "somepath(//foo:app, //foo/...)"

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

# Replace "//foo/..." with a subshell query call (not cquery!) outputting each package, piped into
# a sed call converting "<pkg>" to "//<pkg>:*", piped into a "+"-delimited line merge.
# Output looks like "//foo:*+//foo/bar:*+//foo/baz".
#
$  bazel cquery --universe_scope=//foo:app "somepath(//foo:app, $(bazel query //foo/...
--output=package | sed -e 's/^/\/\//' -e 's/$/:*/' | paste -sd "+" -))"