cquery
, query
का एक वैरिएंट है, जो
select()
को सही तरीके से हैंडल करता है और बिल्ड ग्राफ़ पर विकल्पों के इफ़ेक्ट
को बनाता है.
ऐसा करने के लिए, यह Bazel के विश्लेषण चरण के नतीजों को चलाकर, इन इफ़ेक्ट को इंटिग्रेट करता है. इसके उलट, विकल्पों का आकलन होने से पहले, query
, Bazel के लोड होने के फ़ेज़ के नतीजों पर चलता है.
उदाहरण के लिए:
$ 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
, पूरे आईडी के किसी भी मान्य प्रीफ़िक्स को समझता है, जो गिट शॉर्ट हैश की तरह होता है.
सभी आईडी देखने के लिए, $ 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
, सामान्य Bazel बिल्ड पर चलता है. इस तरह, बिल्ड के दौरान मिलने वाले विकल्पों का इस्तेमाल इनहेरिट करता है.
क्वेरी के विकल्पों का इस्तेमाल करना
--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"], )
जेन रूल अपने टूल को exec कॉन्फ़िगरेशन में कॉन्फ़िगर करते हैं, ताकि नीचे दी गई क्वेरी से ये आउटपुट मिलें:
क्वेरी | टारगेट बनाया गया | आउटपुट |
---|---|---|
bazel cquery "//x:tool" | //x:tool | //x:tool(targetconfig) |
bazel cquery "//x:tool" --universe_scope][=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
(बूलियन, डिफ़ॉल्ट=सही)
Aspects की मदद से जोड़ी गई डिपेंडेंसी शामिल करें.
अगर यह फ़्लैग 'बंद है' पर सेट है, तो cquery somepath(X, Y)
और
cquery deps(X) | grep 'Y'
Y को हटा दें, अगर X सिर्फ़ एक पहलू पर निर्भर करता है.
आउटपुट फ़ॉर्मैट
डिफ़ॉल्ट रूप से, cquery आउटपुट, लेबल और कॉन्फ़िगरेशन पेयर की डिपेंडेंसी-क्रम वाली सूची में नतीजे देता है. नतीजे दिखाने के दूसरे विकल्प भी हैं.
ट्रांज़िशन
--transitions=lite --transitions=full
कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल टॉप लेवल टारगेट के नीचे टारगेट बनाने के लिए किया जाता है. ऐसा टॉप लेवल टारगेट के मुकाबले, अलग-अलग कॉन्फ़िगरेशन में टॉप लेवल टारगेट के नीचे करने के लिए किया जाता है.
उदाहरण के लिए, कोई टारगेट, अपने tools
एट्रिब्यूट की सभी डिपेंडेंसी पर exec कॉन्फ़िगरेशन में ट्रांज़िशन लागू कर सकता है. इन्हें एट्रिब्यूट ट्रांज़िशन के नाम से जाना जाता है. नियम अपने खुद के कॉन्फ़िगरेशन पर भी ट्रांज़िशन लागू कर सकते हैं.
इसे 'नियम क्लास ट्रांज़िशन' कहा जाता है. यह आउटपुट फ़ॉर्मैट, इन ट्रांज़िशन के बारे में जानकारी देता है. जैसे, ये किस तरह के हैं और बिल्ड के विकल्पों पर इनका क्या असर होता है.
यह आउटपुट फ़ॉर्मैट --transitions
फ़्लैग से ट्रिगर होता है, जो डिफ़ॉल्ट रूप से NONE
पर सेट होता है. इसे FULL
या LITE
मोड पर सेट किया जा सकता है. FULL
मोड, नियम क्लास में ट्रांज़िशन और एट्रिब्यूट ट्रांज़िशन के बारे में जानकारी देता है. इसमें ट्रांज़िशन से पहले और बाद के विकल्पों के बीच का अंतर भी शामिल होता है. LITE
मोड, विकल्पों में अंतर के बिना एक जैसी जानकारी दिखाता है.
प्रोटोकॉल मैसेज आउटपुट
--output=proto
इस विकल्प से बनने वाले टारगेट, बाइनरी प्रोटोकॉल बफ़र फ़ॉर्म में प्रिंट हो जाते हैं. प्रोटोकॉल बफ़र की परिभाषा, src/main/protobuf/analysis_v2.proto पर देखी जा सकती है.
CqueryResult
एक टॉप लेवल मैसेज है, जिसमें क्वेरी के नतीजे शामिल हैं. इसमें ConfiguredTarget
मैसेज और Configuration
मैसेज की सूची है. हर ConfiguredTarget
का एक configuration_id
होता है, जिसकी वैल्यू
इससे जुड़े Configuration
मैसेज के id
फ़ील्ड के बराबर होती है.
--[no]proto:include_configurations
डिफ़ॉल्ट रूप से, cquery के नतीजे कॉन्फ़िगर किए गए हर टारगेट के हिस्से के तौर पर कॉन्फ़िगरेशन की जानकारी दिखाते हैं. अगर आपको इस जानकारी को हटाकर, ऐसा प्रोटो आउटपुट पाना है जो क्वेरी के प्रोटो आउटपुट की तरह ही फ़ॉर्मैट किया गया हो, तो इस फ़्लैग को'गलत' पर सेट करें.
प्रोटो आउटपुट से जुड़े विकल्पों के बारे में ज़्यादा जानने के लिए, क्वेरी का प्रोटो आउटपुट दस्तावेज़ देखें.
ग्राफ़ आउटपुट
--output=graph
यह विकल्प, आउटपुट को Graviz के साथ काम करने वाली .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
नाम के फ़ंक्शन के बारे में बताती है. इस फ़ंक्शन को क्वेरी के नतीजे में मौजूद हर टारगेट
के लिए कॉल किया जाता है. इसके अलावा, सुविधा के लिए --starlark:expr
फ़्लैग का इस्तेमाल करके, def format(target): return expr
के तौर पर बताए गए फ़ंक्शन के मुख्य हिस्से को तय किया जा सकता है.
'cquery' स्टारलार्क बोली
Cquery Starlark एनवायरमेंट BUILD या .bzl फ़ाइल से अलग है. इसमें सभी कोर Starlark बिल्ट-इन कॉन्सटेंट और फ़ंक्शन शामिल हैं. साथ ही, इसमें कुछ क्वेरी के हिसाब से नीचे बताए गए फ़ंक्शन भी शामिल हैं, लेकिन (उदाहरण के लिए) 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
को यह नहीं पता कि बिल्ड कौनसी ब्रांच चुनता है. इसलिए, यह सभी ब्रांच शामिल करता है.cquery
की वैल्यू को सटीक बनाने के लिए,query
की तुलना में ज़्यादा ग्राफ़ बनाने की ज़रूरत है. खास तौर पर,cquery
कॉन्फ़िगर किए गए टारगेट का आकलन करता है, जबकिquery
सिर्फ़ टारगेट का आकलन करता है. इसमें ज़्यादा समय लगता है और ज़्यादा मेमोरी इस्तेमाल होती है.cquery
के क्वेरी भाषा में दी गई व्याख्या से, साफ़ तौर पर जानकारी मिलती है औरquery
इससे बचा जा सकता है. उदाहरण के लिए, अगर"//foo"
दो कॉन्फ़िगरेशन में मौजूद है, तोcquery "deps(//foo)"
को किसका इस्तेमाल करना चाहिए? इसमेंconfig
फ़ंक्शन से मदद मिल सकती है.- नया टूल होने के नाते,
cquery
में इस्तेमाल के कुछ उदाहरणों में सहायता उपलब्ध नहीं है. ज़्यादा जानकारी के लिए ऐसी समस्याएं जिनके बारे में हमें पता है देखें.
पहले से मालूम समस्याएं
cquery
"बनाने" के लिए सभी टारगेट का कॉन्फ़िगरेशन एक जैसा होना चाहिए.
क्वेरी का आकलन करने से पहले, cquery
बिल्ड ऐक्शन ट्रिगर होने से ठीक पहले, एक बिल्ड ट्रिगर करता है. यह "builds" वाले टारगेट, डिफ़ॉल्ट रूप से उन सभी लेबल से चुने जाते हैं जो क्वेरी एक्सप्रेशन में दिखते हैं (इसे --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 "+" -))"