BaselCon 2024 का रजिस्ट्रेशन अब शुरू हो गया है!

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

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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](/versions/6.5.0/reference/be/general#test_suite) का ऐक्सेस जैसे आर्टफ़ैक्ट में शामिल नहीं है नियम हो जाएं, क्योंकि वे कॉन्फ़िगर किए गए टारगेट नहीं हैं. पहली ऐसेट के लिए, [aquery](/versions/6.5.0/docs/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

होस्ट कॉन्फ़िगरेशन, खास आईडी (HOST) का इस्तेमाल करता है. नॉन-जनरेट नहीं की गई सोर्स फ़ाइलें, जैसे जो आम तौर पर srcs में मिलते हैं, खास आईडी (null) का इस्तेमाल करते हैं (क्योंकि वे कॉन्फ़िगर करने की ज़रूरत नहीं होती).

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 a host-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 (HOST)

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

query का टारगेट पैटर्न देखें दस्तावेज़ देखें.

फ़ंक्शन

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

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

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

expr ::= config(expr, word)

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

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

उदाहरण:

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

$ bazel cquery "deps(//foo)"
//bar (HOST)
//baz (3732cc8)

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

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

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

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

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

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

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

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

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

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

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

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

अगर आप बंद की गई पहलुओं के बारे में क्वेरी करते हैं, तो आपको ऐसी समस्या का सामना करना पड़ सकता है जहां टारगेट 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 एक टॉप लेवल मैसेज है, जिसमें cquery के नतीजे शामिल हैं. यह इसमें ConfiguredTarget मैसेज और Configuration की सूची है मैसेज. हर ConfiguredTarget में एक configuration_id होता है, जिसकी वैल्यू बराबर होती है मैसेज को id फ़ील्ड में डालें.Configuration

--[no]proto:include_configurations

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

query के Proto आउटपुट दस्तावेज़ को देखें की एक कॉपी तैयार करें.

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

--output=graph

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

फ़ाइल आउटपुट

--output=files

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

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

--output=starlark

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

'cquery' स्टारलार्क भाषा

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

build_options(target)

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

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

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

providers(target) ऐसा मैप दिखाता है जिसकी कुंजियों के नाम हैं सेवा देने वाले (उदाहरण के लिए, "DefaultInfo") और जिनकी वैल्यू 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 को नहीं पता कि जो पसंद की सभी शाखाएं बन जाती हैं. इसलिए, सभी ब्रांच को शामिल करने से यह संख्या बहुत ज़्यादा बढ़ जाती है.
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 एट्रिब्यूट का इस्तेमाल करता है - इसका मतलब है कि यह होस्ट कॉन्फ़िगरेशन.

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

$ 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 (host_config)
...

    $ bazel cquery "//foo:tool"
tool(host_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 "+" -))"