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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें स्रोत देखें

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

यह लक्ष्य हासिल करने के लिए, बेज़ेल के विश्लेषण फ़ेज़ के नतीजों पर काम करता है, जो इन इफ़ेक्ट को इंटिग्रेट करता है. 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](/reference/be/general#test_suite) के नियमों का ऐक्सेस होता है, क्योंकि ये कॉन्फ़िगरेशन कॉन्फ़िगर नहीं किए जाते. पिछले वाले के लिए, [aquery](/query/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 Short हैश की तरह ही होता है. पूरा आईडी देखने के लिए, $ bazel config चलाएं.

टारगेट पैटर्न का आकलन

cquery के लिए, //foo का मतलब 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_library(
    name = "tool",
)

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

क्वेरी टारगेट बनाया गया आउटपुट
bazel cquery "//x:tool" //x:tool //x:tool(targetconfig)
bazel cquery "//x:tool" --universe_scope{8}x:my_gen" //x:my_gen //x:tool(execconfig)

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

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

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

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

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

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

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

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

अगर आप बड़ी क्वेरी के मेमोरी प्रभाव को लेकर चिंतित नहीं हैं, तो अपने फ़्लैग में डिफ़ॉल्ट रूप से यह फ़्लैग सक्षम करें.

अगर क्वेरी के नतीजे बंद किए जाते हैं, तो आपके सामने ऐसी समस्या आ सकती है जिसमें टारगेट X का इस्तेमाल करते समय टारगेट Y काम न करे. हालांकि, cquery somepath(Y, X) और cquery deps(Y) | grep 'X' से कोई नतीजा नहीं मिलता, क्योंकि डिपेंडेंसी किसी नतीजे पर निर्भर करती है.

आउटपुट फ़ॉर्मैट

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

ट्रांज़िशन

--transitions=lite
--transitions=full

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

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

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

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

--output=proto

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

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

--[no]प्रोटो:शामिल करें_कॉन्फ़िगरेशन

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

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

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

--output=graph

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

फ़ाइलों का आउटपुट

--output=files

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

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

--output=starlark

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

'cquery' Starlar बोली

Cquery Starlark एनवायरमेंट, BUILD या .bzl फ़ाइल से अलग होता है. इसमें सभी Core Starlark पहले से मौजूद कॉन्सटेंट और फ़ंक्शन, नीचे दी गई कुछ cquery-specific कॉन्सटेंट और फ़ंक्शन शामिल हैं, लेकिन उदाहरण के लिए glob, native या rule. ये काम नहीं करते.

build_options(टारगेट)

build_options(target) ऐसा मैप दिखाता है जिसकी कुंजियां, बिल्ड विकल्प आइडेंटिफ़ायर (कॉन्फ़िगरेशन देखें) होती हैं और जिनकी वैल्यू उनकी Starlark वैल्यू होती हैं. ऐसे बिल्ड विकल्प जिनके मान कानूनी 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 बनाम query

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

  • cquery आपके बनाए गए ग्राफ़ को मॉडल करने के लिए, select() की खास ब्रांच का इस्तेमाल करता है. query को यह नहीं पता होता कि बिल्ड किस ब्रांच को चुनता है. इसलिए, सभी ब्रांच को शामिल करके ज़रूरत से ज़्यादा इस्तेमाल करें.
  • cquery के सटीक डेटा की तुलना में, query के मुकाबले ज़्यादा ग्राफ़ बनाना ज़रूरी है. खास तौर पर, cquery कॉन्फ़िगर किए गए टारगेट का आकलन करता है, जबकि query सिर्फ़ टारगेट का आकलन करता है. इसमें ज़्यादा समय लगता है और ज़्यादा मेमोरी का इस्तेमाल होता है.
  • cquery को क्वेरी भाषा के बारे में समझने से, यह साफ़ तौर पर पता नहीं चलता कि query किस तरह की भाषा का इस्तेमाल नहीं करता. उदाहरण के लिए, अगर "//foo" दो कॉन्फ़िगरेशन में मौजूद है, तो cquery "deps(//foo)" को किस कॉन्फ़िगरेशन का इस्तेमाल करना चाहिए? [config](#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 पिछले निर्देशों से अपने-आप बिल्ड ग्राफ़ को वाइप नहीं करता और इस वजह से इसमें पिछली क्वेरी के नतीजे शामिल हो सकते हैं. उदाहरण के लिए, genquery अपने tools एट्रिब्यूट पर एक ट्रांज़िशन प्रोसेस करता है - यानी कि यह अपने टूल को exex कॉन्फ़िगरेशन में कॉन्फ़िगर करता है.

आप उस ट्रांज़िशन के असर को नीचे देख सकते हैं.

$ 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)

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

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

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

अगर आपको ये समस्याएं आती हैं, तो:

$ 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 "+" -))"