หน้านี้ได้รับการแปลโดย Cloud Translation API

ข้อมูลอ้างอิงข้อความค้นหา Bazel

รายงานปัญหา ดูแหล่งที่มา /3} /4} {3/4} {3/4} {3/4} {3/4} /4.

หน้านี้คือคู่มืออ้างอิงสำหรับภาษาของคำค้นหา Bazel ที่ใช้เมื่อคุณใช้ bazel query เพื่อวิเคราะห์ทรัพยากร Dependency ของบิลด์ ทั้งยังมีคำอธิบายรูปแบบเอาต์พุตที่ bazel query รองรับด้วย

สำหรับกรณีการใช้งานที่นำไปปฏิบัติได้จริง โปรดดูวิธีการเกี่ยวกับการค้นหาด้วย Bazel

การอ้างอิงการค้นหาเพิ่มเติม

นอกเหนือจาก query ซึ่งแสดงในกราฟเป้าหมายสำหรับช่วงโหลดหลังโหลดแล้ว Bard ยังมีการค้นหากราฟการดำเนินการและการค้นหาที่กำหนดค่าได้ด้วย

การค้นหากราฟการดำเนินการ

การค้นหากราฟการดำเนินการ (aquery) จะดำเนินการในกราฟเป้าหมายที่กำหนดค่าไว้หลังการวิเคราะห์ และแสดงข้อมูลเกี่ยวกับการดำเนินการ อาร์ติแฟกต์ และความสัมพันธ์ aquery มีประโยชน์เมื่อคุณสนใจพร็อพเพอร์ตี้ของการดำเนินการ/อาร์ติแฟกต์ที่สร้างขึ้นจากกราฟเป้าหมายที่กําหนดค่าไว้ เช่น การเรียกใช้คำสั่งจริงรวมถึงอินพุต เอาต์พุต และการช่วยจำ

ดูรายละเอียดเพิ่มเติมได้ที่ข้อมูลอ้างอิงการค้นหา

การค้นหาที่กำหนดค่าได้

การค้นหา Bazel แบบเดิมจะทำงานบนกราฟเป้าหมายหลังการโหลด จึงไม่มีแนวคิดของการกำหนดค่าและแนวคิดที่เกี่ยวข้อง โปรดทราบว่าไม่ได้เป็นคำตอบสำหรับคำสั่งที่เลือกอย่างถูกต้อง แต่จะแสดงวิธีแก้ปัญหาที่เป็นไปได้ทั้งหมดของการเลือก อย่างไรก็ตาม สภาพแวดล้อมการค้นหาที่กำหนดค่าได้ cquery จะจัดการการกำหนดค่าได้อย่างถูกต้อง แต่ไม่มีฟังก์ชันการทำงานทั้งหมดของการค้นหาดั้งเดิมนี้

ดูรายละเอียดเพิ่มเติมได้ที่ข้อมูลอ้างอิง BigQuery

ตัวอย่าง

ผู้คนใช้ bazel query อย่างไร ตัวอย่างทั่วไปมีดังนี้

ทำไมต้นไม้ //foo จึงขึ้นอยู่กับ //bar/baz แสดงเส้นทาง:

somepath(foo/..., //bar/baz:all)

การทดสอบ foo ทั้งหมดไลบรารี C++ จะขึ้นอยู่กับว่าเป้าหมาย foo_bin ไม่ได้ทำ

kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))

โทเค็น: ไวยากรณ์คำศัพท์

นิพจน์ในภาษาที่ใช้ค้นหาประกอบด้วยโทเค็นต่อไปนี้

คีย์เวิร์ด เช่น let คีย์เวิร์ดคือคำที่สงวนไว้ของภาษานั้นๆ ซึ่งจะอธิบายแต่ละคำด้านล่างนี้ ชุดคีย์เวิร์ดที่สมบูรณ์ ได้แก่
- except
- in
- intersect
- let
- set
- union
คำ เช่น "foo/..." หรือ ".*test rule" หรือ "//bar/baz:all" หากลำดับอักขระเป็น "เครื่องหมายคำพูด" (ขึ้นต้นและลงท้ายด้วยเครื่องหมายคำพูดเดี่ยว " หรือ ขึ้นต้นและลงท้ายด้วยเครื่องหมายคำพูดคู่ ") แสดงว่าเป็นคำ หากไม่ได้ยกข้อความตามลำดับอักขระ มา ระบบอาจยังคงแยกวิเคราะห์เป็นคำ คำที่ไม่ใส่เครื่องหมายคำพูดคือลำดับอักขระที่มาจากตัวอักษร A-Za-z, ตัวเลข 0-9 และสัญลักษณ์พิเศษ */@.-_:$~[] (เครื่องหมายดอกจัน เครื่องหมายทับ ที่ จุด ขีดกลาง ขีดล่าง โคลอน ดอลลาร์ เครื่องหมายดอลลาร์ เครื่องหมายทิลเดอ วงเล็บเหลี่ยมเปิด วงเล็บเหลี่ยมปิด) อย่างไรก็ตาม คำที่ไม่ได้ใส่เครื่องหมายคำพูดต้องไม่ขึ้นต้นด้วยขีดกลาง - หรือเครื่องหมายดอกจัน * แม้ว่า [ชื่อเป้าหมาย][(/concepts/labels#target-names) สัมพัทธ์อาจขึ้นต้นด้วยอักขระเหล่านั้นก็ตาม

นอกจากนี้ คำที่ไม่ได้ใส่เครื่องหมายคำพูดต้องไม่มีอักขระบวก + หรือเท่ากับเครื่องหมาย = แม้ว่าอักขระเหล่านั้นจะได้รับอนุญาตในชื่อเป้าหมายก็ตาม เมื่อเขียนโค้ดที่สร้างนิพจน์คำค้นหา ควรใส่เครื่องหมายคำพูดกำกับไว้

จำเป็นต้องระบุเมื่อเขียนสคริปต์ที่สร้างนิพจน์การค้นหาของ Bazel จากค่าที่ผู้ใช้ระบุ
```
 //foo:bar+wiz    # WRONG: scanned as //foo:bar + wiz.
 //foo:bar=wiz    # WRONG: scanned as //foo:bar = wiz.
 "//foo:bar+wiz"  # OK.
 "//foo:bar=wiz"  # OK.
```
โปรดทราบว่าการยกมานี้นอกเหนือจากการยกคำพูดที่ เชลล์ของคุณอาจกำหนดไว้ เช่น
```
bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.
```
เมื่อมีการยกข้อความมา คีย์เวิร์ดจะถือว่าเป็นคำทั่วไป เช่น some เป็นคีย์เวิร์ด แต่ "บางคำ" คือคำ ทั้ง foo และ "foo" เป็นคำ

อย่างไรก็ตาม โปรดระมัดระวังเมื่อใช้เครื่องหมายคำพูดเดี่ยวหรือคู่ในชื่อเป้าหมาย เมื่อยกชื่อเป้าหมายอย่างน้อย 1 ชื่อ ให้ใช้เครื่องหมายคำพูดเพียงประเภทเดียว (เครื่องหมายคำพูดเดี่ยวหรือเครื่องหมายคำพูดคู่ทั้งหมด)

ต่อไปนี้คือตัวอย่างของสตริงคำค้นหา Java
```
  'a"'a'         # WRONG: Error message: unclosed quotation.
  "a'"a"         # WRONG: Error message: unclosed quotation.
  '"a" + 'a''    # WRONG: Error message: unexpected token 'a' after query expression '"a" + '
  "'a' + "a""    # WRONG: Error message: unexpected token 'a' after query expression ''a' + '
  "a'a"          # OK.
  'a"a'          # OK.
  '"a" + "a"'    # OK
  "'a' + 'a'"    # OK
```
เราเลือกไวยากรณ์นี้เพื่อให้ไม่จำเป็นต้องใช้เครื่องหมายคำพูดในกรณีทั่วไป ตัวอย่าง ".*test rule" (ผิดปกติ) ต้องมีเครื่องหมายคำพูด โดยขึ้นต้นด้วยจุดและมีเว้นวรรค การอ้างอิง "cc_library" เป็นไปโดยไม่จำเป็นแต่ก็ไม่เป็นอันตราย
เครื่องหมายวรรคตอน เช่น วงเล็บ () จุด . และเครื่องหมายจุลภาค , คำที่มีเครื่องหมายวรรคตอน (นอกเหนือจากข้อยกเว้นที่ระบุไว้ข้างต้น) จะต้องอยู่ในเครื่องหมายคำพูด

ระบบจะละเว้นอักขระช่องว่างนอกคำที่ยกมา

แนวคิดภาษาในการค้นหา Bazel

ภาษาที่ใช้ค้นหา Bazel คือภาษาของนิพจน์ ทุกนิพจน์จะประเมินชุดเป้าหมายที่เรียงลำดับบางส่วนหรือเทียบเท่ากราฟ (DAG) ของเป้าหมาย นี่เป็นประเภทข้อมูลเดียว

การตั้งค่าและกราฟอ้างอิงถึงประเภทข้อมูลเดียวกัน แต่เน้นที่แง่มุมต่างๆ เช่น

Set: ลำดับบางส่วนของเป้าหมายไม่น่าสนใจ
กราฟ: ลำดับบางส่วนของเป้าหมายมีนัยสำคัญ

วงจรในกราฟทรัพยากร Dependency

กราฟทรัพยากร Dependency ควรเป็นแบบวนซ้ำ

อัลกอริทึมที่ใช้โดยภาษาค้นหานั้นมีวัตถุประสงค์เพื่อใช้ในกราฟแบบวนซ้ำ แต่มีประสิทธิภาพต่อวงจร ไม่มีการระบุถึงรายละเอียดวิธีการจัดการวงจร ซึ่งไม่ควรนำมาใช้

ทรัพยากร Dependency โดยนัย

นอกจากการสร้างทรัพยากร Dependency ที่กําหนดไว้อย่างชัดแจ้งในไฟล์ BUILD แล้ว Bazel ยังเพิ่มทรัพยากร Dependency แบบ implicit เพิ่มเติมลงในกฎด้วย เช่น กฎ Java ทุกข้อจะขึ้นอยู่กับ JavaBuilder โดยปริยาย ทรัพยากร Dependency โดยนัยสร้างขึ้นมาโดยใช้แอตทริบิวต์ที่ขึ้นต้นด้วย $ และลบล้างไม่ได้ในไฟล์ BUILD

ตามค่าเริ่มต้น bazel query จะพิจารณาทรัพยากร Dependency โดยนัยเมื่อคำนวณผลการค้นหา คุณเปลี่ยนลักษณะการทำงานนี้ได้ด้วยตัวเลือก --[no]implicit_deps โปรดทราบว่าเนื่องจากคำค้นหาไม่พิจารณาการกำหนดค่า ระบบจึงไม่พิจารณา Toolchain ที่เป็นไปได้

ความเสียง

นิพจน์ภาษาของคำค้นหา Bazel จะทำงานเหนือกราฟการขึ้นต่อกันของบิลด์ ซึ่งเป็นกราฟที่กำหนดโดยการประกาศกฎทั้งหมดในไฟล์ BUILD ทั้งหมดโดยปริยาย คุณควรเข้าใจว่ากราฟนี้ค่อนข้างเป็นนามธรรม และไม่ถือว่าเป็นคำอธิบายที่สมบูรณ์เกี่ยวกับวิธีดำเนินการตามขั้นตอนทั้งหมดของการสร้าง คุณจำเป็นต้องมีการกำหนดค่าในการสร้างบิลด์เช่นกัน ดูรายละเอียดเพิ่มเติมได้ที่ส่วนการกำหนดค่าในคู่มือผู้ใช้

ผลจากการประเมินนิพจน์ในภาษาคำค้นหา Bazel จะเป็นจริงสำหรับการกำหนดค่าทั้งหมด ซึ่งหมายความว่าอาจเป็นค่าโดยประมาณมากเกินไป และไม่แม่นยำเสียทีเดียว หากคุณใช้เครื่องมือ Query เพื่อคำนวณชุดของไฟล์ต้นฉบับทั้งหมดที่ต้องใช้ระหว่างบิลด์ เครื่องมือดังกล่าวอาจรายงานมากเกินกว่าที่จำเป็นจริง เช่น เครื่องมือ Query จะรวมไฟล์ทั้งหมดที่จำเป็นต่อการรองรับการแปลข้อความ แม้ว่าคุณจะไม่ได้ตั้งใจใช้ฟีเจอร์ดังกล่าวในงานสร้างก็ตาม

เกี่ยวกับการรักษาลำดับกราฟ

การดำเนินการจะเก็บข้อจำกัดการจัดลำดับ ที่สืบทอดมาจากนิพจน์ย่อย คุณอาจมองว่านี่คือ "กฎแห่งการอนุรักษ์กฎเกณฑ์บางส่วน" ก็ได้ ลองพิจารณาตัวอย่าง เช่น หากคุณออกคำค้นหาเพื่อกำหนดการปิดการขึ้นต่อกันแบบทรานซิทีฟของเป้าหมายที่เฉพาะเจาะจง ชุดผลลัพธ์จะเรียงลำดับตามกราฟทรัพยากร Dependency หากคุณกรองซึ่งตั้งค่าให้รวมเฉพาะเป้าหมายประเภท file ความสัมพันธ์ในการจัดลำดับบางส่วนแบบสลายเดียวกันระหว่างเป้าหมายทุกคู่ในเซตย่อยที่ได้ แม้ว่าจะไม่มีคู่ใดที่เชื่อมต่อกันโดยตรงในกราฟต้นฉบับก็ตาม (ไม่มีขอบของไฟล์ในกราฟทรัพยากร Dependency ของบิลด์)

แต่ในขณะที่โอเปอเรเตอร์ทั้งหมดเก็บรักษาลำดับไว้ แต่การดำเนินการบางอย่าง เช่น การดำเนินการตั้งค่าจะไม่นำข้อจำกัดการจัดลำดับของตนเองมาใช้ ลองพิจารณานิพจน์นี้

deps(x) union y

รับประกันได้ว่าลำดับของชุดผลลัพธ์สุดท้ายจะคงข้อจำกัดการจัดลำดับทั้งหมดของนิพจน์ย่อยไว้ กล่าวคือ ทรัพยากร Dependency แบบสับเปลี่ยนทั้งหมดของ x จะได้รับการเรียงลำดับอย่างถูกต้องโดยคำนึงถึงกันและกัน อย่างไรก็ตาม การค้นหาไม่ได้รับประกันถึงลำดับของเป้าหมายใน y หรือลำดับของเป้าหมายใน deps(x) ที่สัมพันธ์กับเป้าหมายใน y (ยกเว้นเป้าหมายเหล่านั้นใน y ที่อยู่ใน deps(x) เช่นกัน)

โอเปอเรเตอร์ที่ทำให้เกิดข้อจำกัดในการสั่งซื้อ ได้แก่ allpaths, deps, rdeps, somepath และไวลด์การ์ดรูปแบบเป้าหมาย package:*, dir/... ฯลฯ

การค้นหาเกี่ยวกับท้องฟ้า

Sky Query คือโหมดของคำค้นหาที่ดำเนินการตามขอบเขตระดับจักรวาลที่ระบุไว้

ฟังก์ชันพิเศษมีอยู่ใน SkyQuery เท่านั้น

โหมด Sky Query มีฟังก์ชันการค้นหาเพิ่มเติม allrdeps และ rbuildfiles ฟังก์ชันเหล่านี้ทำงานในขอบเขตทั้งจักรวาล (ซึ่งเป็นเหตุผลที่ทำให้ไม่สมเหตุสมผลสำหรับการค้นหาปกติ)

การระบุขอบเขตจักรวาล

โหมด Sky Query ได้รับการเปิดใช้งานโดยการส่งผ่าน 2 รายการต่อไปนี้: (--universe_scope หรือ --infer_universe_scope) และ --order_output=no --universe_scope=<target_pattern1>,...,<target_patternN> จะบอกให้คำค้นหาโหลดการปิดแบบทรานซิทีฟของรูปแบบเป้าหมายที่ระบุโดยรูปแบบเป้าหมายไว้ล่วงหน้า ซึ่งอาจเป็นได้ทั้งบวกและลบ จากนั้นคำค้นหาทั้งหมดจะได้รับการประเมินใน "ขอบเขต" นี้ โดยเฉพาะอย่างยิ่ง โอเปอเรเตอร์ allrdeps และ rbuildfiles จะแสดงเฉพาะผลการค้นหาจากขอบเขตนี้ --infer_universe_scope จะบอกให้ Bazel อนุมานค่า --universe_scope จากนิพจน์คำค้นหา ค่าที่อนุมานนี้คือรายการรูปแบบเป้าหมายที่ไม่ซ้ำในนิพจน์คำค้นหา แต่อาจไม่ใช่สิ่งที่คุณต้องการ เช่น

bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"

รายการรูปแบบเป้าหมายที่ไม่ซ้ำในนิพจน์การค้นหานี้คือ ["//my:target"] ดังนั้น Bazel จึงถือว่ารายการนี้เหมือนกับการเรียกใช้

bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"

แต่ผลลัพธ์ของคำค้นหาด้วย --universe_scope นั้นคือ //my:target เท่านั้น ไม่มีทรัพยากร Dependency แบบย้อนกลับของ //my:target จากการสร้างเลย ในทางกลับกัน ให้ลองพิจารณาดังนี้

bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"

นี่คือการเรียกใช้คำค้นหาที่มีความหมายซึ่งกำลังพยายามคำนวณเป้าหมายทดสอบในการขยาย tests ของเป้าหมายภายใต้บางไดเรกทอรีที่ขึ้นอยู่กับเป้าหมายที่มีคำจำกัดความที่ใช้ไฟล์ .bzl ที่เฉพาะเจาะจง ในที่นี้ --infer_universe_scope มีประโยชน์โดยเฉพาะอย่างยิ่งในกรณีที่การใช้ --universe_scope อาจทำให้คุณต้องแยกวิเคราะห์นิพจน์การค้นหาด้วยตัวเอง

ดังนั้นสําหรับนิพจน์คำค้นหาที่ใช้โอเปอเรเตอร์ที่กําหนดขอบเขตระดับสากล เช่น allrdeps และ rbuildfiles ให้ใช้ --infer_universe_scope ก็ต่อเมื่อลักษณะการทำงานเป็นไปตามที่ต้องการ

Sky Query มีข้อดีและข้อเสียบางอย่างเมื่อเทียบกับ Query เริ่มต้น แต่ข้อเสียหลักๆ คือไม่สามารถเรียงลำดับเอาต์พุตตามลำดับกราฟได้ ทำให้ระบบไม่อนุญาตให้ใช้รูปแบบเอาต์พุตบางรูปแบบ ข้อดีคือมีโอเปอเรเตอร์ 2 รายการ (allrdeps และ rbuildfiles) ที่ไม่มีในคำค้นหาเริ่มต้น นอกจากนี้ Sky Query ยังทำงานโดยการดูกราฟ Skyframe แทนการสร้างกราฟใหม่ ซึ่งเป็นสิ่งที่การใช้งานเริ่มต้นทำ ดังนั้นจึงอาจมีบางกรณีที่โหมดนี้ ทำงานเร็วขึ้นและใช้หน่วยความจำน้อยลง

นิพจน์: ไวยากรณ์และความหมายของไวยากรณ์

นี่คือไวยากรณ์ของภาษาในการค้นหา Bazel ซึ่งแสดงในรูปแบบ EBNF

expr ::= word
       | let name = expr in expr
       | (expr)
       | expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr
       | set(word *)
       | word '(' int | word | expr ... ')'

ส่วนต่อไปนี้จะอธิบายการใช้ไวยากรณ์แต่ละรายการตามลำดับ

รูปแบบเป้าหมาย

expr ::= word

ในเชิงไวยากรณ์ รูปแบบเป้าหมายเป็นเพียงคำๆ หนึ่ง โดยจะได้รับการแปลค่าเป็นชุดเป้าหมาย (ไม่เรียงลำดับ) รูปแบบเป้าหมายที่ง่ายที่สุดคือป้ายกำกับที่ระบุเป้าหมายเดี่ยว (ไฟล์หรือกฎ) ตัวอย่างเช่น รูปแบบเป้าหมาย //foo:bar จะประเมินชุดที่มีองค์ประกอบเดียว เป้าหมาย และกฎ bar

รูปแบบเป้าหมายจะทำให้ป้ายกำกับมีไวลด์การ์ดแทนที่แพ็กเกจและเป้าหมาย เช่น foo/...:all (หรือเพียง foo/...) เป็นรูปแบบเป้าหมายที่ประเมินชุดที่มีกฎทั้งหมดซ้ำๆ ภายใต้ไดเรกทอรี foo bar/baz:all เป็นรูปแบบเป้าหมายที่ประเมินชุดที่มีกฎทั้งหมดในแพ็กเกจ bar/baz แต่ไม่ใช่แพ็กเกจย่อย

ในทำนองเดียวกัน foo/...:* เป็นรูปแบบเป้าหมายที่ประเมินชุดที่มีเป้าหมาย (กฎ และ ไฟล์) ทั้งหมดในทุกแพ็กเกจโดยเกิดซ้ำใต้ไดเรกทอรี foo โดย bar/baz:* จะประเมินชุดที่มีเป้าหมายทั้งหมดในแพ็กเกจ bar/baz แต่ไม่ใช่แพ็กเกจย่อย

เนื่องจากไวลด์การ์ด :* จับคู่กับไฟล์และกฎต่างๆ จึงมักมีประโยชน์มากกว่า :all สำหรับการค้นหา ในทางกลับกัน ไวลด์การ์ด :all (โดยนัยในรูปแบบเป้าหมาย เช่น foo/...) มักจะมีประโยชน์มากกว่าสำหรับบิลด์

รูปแบบเป้าหมาย bazel query ทำงานเหมือนกับเป้าหมายของบิลด์ bazel build สำหรับรายละเอียดเพิ่มเติม โปรดดูรูปแบบเป้าหมาย หรือพิมพ์ bazel help target-syntax

รูปแบบเป้าหมายอาจประเมินเป็นชุดเดี่ยว (ในกรณีของป้ายกำกับ) ไปยังชุดที่มีองค์ประกอบจำนวนมาก (เช่นในกรณีของ foo/... ซึ่งมีองค์ประกอบหลายพันรายการ) หรือกับชุดว่างเปล่าหากรูปแบบเป้าหมายไม่ตรงกับเป้าหมาย

โหนดทั้งหมดในผลลัพธ์ของนิพจน์รูปแบบเป้าหมายมีการจัดเรียงลำดับอย่างถูกต้องโดยสัมพันธ์กับกันและกันตามความสัมพันธ์ของทรัพยากร Dependency ดังนั้นผลลัพธ์ของ foo:* ไม่ใช่แค่ชุดของเป้าหมายในแพ็กเกจ foo แต่ยังเป็น กราฟ เหนือเป้าหมายเหล่านั้นด้วย (ไม่มีการรับประกันเกี่ยวกับลำดับที่สัมพันธ์กันของโหนดผลลัพธ์กับโหนดอื่นๆ) ดูรายละเอียดเพิ่มเติมได้ที่ส่วน ลำดับกราฟ

ตัวแปร

expr ::= let name = expr₁ in expr₂
       | $name

ภาษาในการค้นหา Bazel ทำให้กำหนดคำจำกัดความและการอ้างอิงตัวแปรได้ ผลลัพธ์ของการประเมินนิพจน์ let เหมือนกับของ expr₂ โดยจะแทนที่ตัวแปร name โดยไม่เสียค่าใช้จ่ายทั้งหมดด้วยค่า expr₁

เช่น let v = foo/... in allpaths($v, //common) intersect $v เทียบเท่ากับ allpaths(foo/...,//common) intersect foo/...

การเกิดการอ้างอิงตัวแปร name อื่นที่ไม่ใช่ในนิพจน์ let name = ... ที่ล้อมรอบเป็นข้อผิดพลาด กล่าวคือ นิพจน์คำค้นหาระดับบนสุดจะมีตัวแปรอิสระไม่ได้

ในการสร้างไวยากรณ์ข้างต้น name จะเหมือนกับ word แต่มีข้อจำกัดเพิ่มเติมว่าต้องเป็นตัวระบุทางกฎหมายในภาษาโปรแกรม C การอ้างอิงตัวแปรจะต้องเพิ่มอักขระ "$" ไว้หน้า

นิพจน์ let แต่ละรายการจะกำหนดตัวแปรเพียง 1 ตัว แต่คุณจะซ้อนได้

ทั้งรูปแบบเป้าหมายและการอ้างอิงตัวแปรจะประกอบด้วยโทเค็นเพียงคำเดียว ซึ่งทำให้เกิดความกำกวมในไวยากรณ์ อย่างไรก็ตาม จะไม่มีความคลุมเครือทางความหมาย เนื่องจากชุดย่อยของคำที่เป็นชื่อตัวแปรทางกฎหมายนั้นไม่ต่อเนื่องจากชุดย่อยของคำที่เป็นรูปแบบเป้าหมายทางกฎหมาย

ในทางเทคนิคแล้ว นิพจน์ let จะไม่เพิ่มความชัดเจนของภาษาในการค้นหา คำค้นหาใดๆ ที่แสดงได้ในภาษานั้นก็จะแสดงโดยไม่มีคำเหล่านั้นได้ อย่างไรก็ตาม เมตริกเหล่านี้ช่วยเพิ่มความกระชับของคำค้นหาจำนวนมาก และอาจนำไปสู่การประเมินคำค้นหาที่มีประสิทธิภาพมากขึ้นด้วย

นิพจน์ที่อยู่ในวงเล็บ

expr ::= (expr)

วงเล็บเชื่อมโยงนิพจน์ย่อยเพื่อบังคับลำดับของการประเมิน นิพจน์ที่อยู่ในวงเล็บจะประเมินค่าของอาร์กิวเมนต์

การดำเนินการชุดพีชคณิต: อินเตอร์เซกชัน ยูเนียน เซตความแตกต่าง

expr ::= expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr

โอเปอเรเตอร์ทั้ง 3 รายการนี้จะคำนวณการดำเนินการชุดปกติเหนืออาร์กิวเมนต์ โอเปอเรเตอร์แต่ละรายการมี 2 รูปแบบ ได้แก่ รูปแบบเล็กน้อย เช่น intersect และรูปแบบสัญลักษณ์ เช่น ^ ทั้งสองรูปแบบเหมือนกัน กล่าวคือรูปแบบสัญลักษณ์จะพิมพ์ได้เร็วกว่า (เพื่อความชัดเจน ส่วนที่เหลือของหน้านี้ใช้รูปทั่วไป)

ตัวอย่างเช่น

foo/... except foo/bar/...

ประเมินได้ชุดของเป้าหมายที่ตรงกับ foo/... แต่ไม่ตรงกับ foo/bar/...

คุณสามารถเขียน Query แบบเดียวกับ

foo/... - foo/bar/...

การดำเนินการ intersect (^) และ union (+) เป็นแบบสลับกัน (แบบสมมาตร) except (-) เป็นแบบไม่สมมาตร โปรแกรมแยกวิเคราะห์นี้จะมองว่าโอเปอเรเตอร์ทั้ง 3 รายการนี้เป็นแบบเชื่อมต่อกันด้านซ้ายและมีลำดับความสำคัญเท่ากัน ดังนั้นคุณอาจต้องใส่วงเล็บ ตัวอย่างเช่น สองนิพจน์แรกนั้นเทียบเท่ากัน แต่นิพจน์ที่สามไม่ใช่

x intersect y union z
(x intersect y) union z
x intersect (y union z)

อ่านเป้าหมายจากแหล่งที่มาภายนอก: ตั้งค่าแล้ว

expr ::= set(word *)

โอเปอเรเตอร์ set(a b c ...) จะคำนวณการรวมของชุดรูปแบบเป้าหมาย 0 รายการหรือมากกว่า โดยคั่นด้วยช่องว่าง (โดยไม่มีคอมมา)

set() เมื่อใช้ร่วมกับฟีเจอร์ $(...) ของ Bourne Shell แล้ว เป็นวิธีการบันทึกผลลัพธ์ของการค้นหาหนึ่งๆ ในไฟล์ข้อความทั่วไป โดยจัดการกับไฟล์ข้อความนั้นโดยใช้โปรแกรมอื่น (เช่น เครื่องมือ Shell ของ UNIX มาตรฐาน) จากนั้นจึงนำผลลัพธ์กลับไปยังเครื่องมือ Query เป็นค่าเพื่อการประมวลผลเพิ่มเติม เช่น

bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"

ในตัวอย่างถัดไป kind(cc_library, deps(//some_dir/foo:main, 5)) จะคํานวณโดยการกรองค่า maxrank โดยใช้โปรแกรม awk

bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"

ในตัวอย่างเหล่านี้ $(<foo) เป็นชวเลขสำหรับ $(cat foo) แต่อาจใช้คำสั่ง Shell อื่นที่ไม่ใช่ cat ได้ด้วย เช่น คำสั่ง awk ก่อนหน้านี้

ฟังก์ชัน

expr ::= word '(' int | word | expr ... ')'

ภาษาในการค้นหาจะกำหนดฟังก์ชันหลายรายการ ชื่อของฟังก์ชันจะกำหนดจำนวนและประเภทของอาร์กิวเมนต์ที่ต้องการ โดยมีฟังก์ชันต่อไปนี้

allpaths
attr
buildfiles
rbuildfiles
deps
filter
kind
labels
loadfiles
rdeps
allrdeps
same_pkg_direct_rdeps
siblings
some
somepath
tests
visible

การปิดแบบทางอ้อมของทรัพยากร Dependency: deps

expr ::= deps(expr)
       | deps(expr, depth)

โอเปอเรเตอร์ deps(x) จะประเมินกราฟที่สร้างขึ้นจากการปิดแบบสับเปลี่ยนของทรัพยากร Dependency ของชุดอาร์กิวเมนต์ x ตัวอย่างเช่น ค่าของ deps(//foo) คือกราฟการขึ้นต่อที่อิงตามโหนดเดี่ยว foo รวมถึงการขึ้นต่อกันทั้งหมดของโหนดนี้ ค่าของ deps(foo/...) คือกราฟทรัพยากร Dependency ที่รูทเป็นกฎทั้งหมดในทุกแพ็กเกจที่อยู่ใต้ไดเรกทอรี foo ในบริบทนี้ "dependencies" หมายถึงกฎและเป้าหมายไฟล์เท่านั้น ดังนั้นไฟล์ BUILD และ Starlark ที่จำเป็นในการสร้างเป้าหมายเหล่านี้จึงไม่ได้รวมไว้ที่นี่ สำหรับการดำเนินการดังกล่าว คุณควรใช้โอเปอเรเตอร์ buildfiles

กราฟผลลัพธ์จะเรียงลำดับตามความสัมพันธ์ในการพึ่งพา ดูรายละเอียดเพิ่มเติมได้ที่ส่วนลำดับกราฟ

โอเปอเรเตอร์ deps ยอมรับอาร์กิวเมนต์ที่ 2 ซึ่งไม่บังคับ ซึ่งเป็นจำนวนเต็มที่ระบุขอบเขตบนของความลึกของการค้นหา ดังนั้น deps(foo:*, 0) จะแสดงผลเป้าหมายทั้งหมดในแพ็กเกจ foo ขณะที่ deps(foo:*, 1) ยังรวมข้อกำหนดเบื้องต้นโดยตรงของเป้าหมายในแพ็กเกจ foo และ deps(foo:*, 2) รวมโหนดที่เข้าถึงได้โดยตรงจากโหนดใน deps(foo:*, 1) และต่อไปเรื่อยๆ (ตัวเลขเหล่านี้สอดคล้องกับอันดับที่แสดงในรูปแบบเอาต์พุต minrank) หากไม่ใส่พารามิเตอร์ depth การค้นหาจะไม่มีขอบเขต โดยจะคำนวณการปิดทรานซิทีฟแบบสะท้อนกลับของข้อกำหนดเบื้องต้น

การปิดแบบทางอ้อมของทรัพยากร Dependency แบบย้อนกลับ: rdeps

expr ::= rdeps(expr, expr)
       | rdeps(expr, expr, depth)

โอเปอเรเตอร์ rdeps(u, x) จะประเมินทรัพยากร Dependency แบบย้อนกลับของชุดอาร์กิวเมนต์ x ภายในทรานซิทีฟปิดของชุดจักรวาล u

โอเปอเรเตอร์ rdeps ยอมรับอาร์กิวเมนต์ที่สาม (ไม่บังคับ) ซึ่งเป็นจำนวนเต็มที่ระบุขอบเขตบนของความลึกของการค้นหา กราฟที่เป็นผลลัพธ์จะรวมเฉพาะโหนดที่อยู่ในระยะของความลึกที่ระบุจากโหนดใดๆ ในชุดอาร์กิวเมนต์ ดังนั้น rdeps(//foo, //common, 1) จะประเมินโหนดทั้งหมดเมื่อปิดทรานซิทีฟของ //foo ซึ่งขึ้นอยู่กับ //common โดยตรง (ตัวเลขเหล่านี้สอดคล้องกับอันดับที่แสดงในรูปแบบเอาต์พุต minrank) หากไม่ระบุพารามิเตอร์ depth การค้นหาจะไม่มีขอบเขต

การปิดแบบทางอ้อมของทรัพยากร Dependency แบบย้อนกลับทั้งหมด: allrdeps

expr ::= allrdeps(expr)
       | allrdeps(expr, depth)

โอเปอเรเตอร์ allrdeps ทํางานเหมือนกับโอเปอเรเตอร์ rdeps เว้นแต่ "ชุดจักรวาล" จะเป็นอะไรก็ตามที่แฟล็ก --universe_scope ประเมินไว้ แทนที่จะระบุแยกต่างหาก ดังนั้น หากระบบผ่าน --universe_scope=//foo/... แล้ว allrdeps(//bar) จะเท่ากับ rdeps(//foo/..., //bar)

ทรัพยากร Dependency แบบย้อนกลับโดยตรงในแพ็กเกจเดียวกัน: same_pkg_direct_rdeps

expr ::= same_pkg_direct_rdeps(expr)

โอเปอเรเตอร์ same_pkg_direct_rdeps(x) จะประเมินชุดเป้าหมายทั้งหมดที่อยู่ในแพ็กเกจเดียวกันกับเป้าหมายในชุดอาร์กิวเมนต์ ซึ่งขึ้นอยู่กับเป้าหมายโดยตรง

การจัดการกับแพ็กเกจของเป้าหมาย: พี่น้อง

expr ::= siblings(expr)

โอเปอเรเตอร์ siblings(x) จะประเมินชุดเป้าหมายทั้งหมดที่อยู่ในแพ็กเกจเดียวกับเป้าหมายในชุดอาร์กิวเมนต์

เลือกเอง: บางส่วน

expr ::= some(expr)
       | some(expr, count )

โอเปอเรเตอร์ some(x, k) จะเลือกเป้าหมายไม่เกิน k รายการโดยไม่มีกฎเกณฑ์จากชุดอาร์กิวเมนต์ x และประเมินได้เป็นชุดที่มีเฉพาะเป้าหมายเหล่านั้น คุณจะใส่พารามิเตอร์ k หรือไม่ก็ได้ หากไม่มี ผลลัพธ์จะเป็นชุดเดี่ยวที่มีการเลือกเป้าหมายเพียง 1 รายการโดยไม่มีกฎเกณฑ์ หากขนาดของชุดอาร์กิวเมนต์ x เล็กกว่า k ระบบจะแสดงผลชุดอาร์กิวเมนต์ x ทั้งหมด

ตัวอย่างเช่น นิพจน์ some(//foo:main union //bar:baz) จะประเมินชุดเดี่ยวที่มี //foo:main หรือ //bar:baz แม้จะไม่ได้กำหนดไว้เป็นชุดใด นิพจน์ some(//foo:main union //bar:baz, 2) หรือ some(//foo:main union //bar:baz, 3) จะแสดงผลทั้ง //foo:main และ //bar:baz

หากอาร์กิวเมนต์เป็นเดี่ยวๆ some จะคำนวณฟังก์ชันข้อมูลประจำตัว: some(//foo:main) ที่เทียบเท่ากับ //foo:main

โดยจะเกิดข้อผิดพลาดหากชุดอาร์กิวเมนต์ที่ระบุว่างเปล่า ดังเช่นในนิพจน์ some(//foo:main intersect //bar:baz)

โอเปอเรเตอร์เส้นทาง: somepath, allpaths

expr ::= somepath(expr, expr)
       | allpaths(expr, expr)

โอเปอเรเตอร์ somepath(S, E) และ allpaths(S, E) จะคำนวณเส้นทางระหว่างเป้าหมาย 2 ชุด การค้นหาทั้ง 2 แบบยอมรับอาร์กิวเมนต์ 2 รายการ คือ S ชุดของจุดเริ่มต้นและชุดจุดสิ้นสุด E somepath จะแสดงผลกราฟของโหนดในเส้นทางที่กำหนดเองบางจากเป้าหมายใน S ไปยังเป้าหมายใน E allpaths จะแสดงผลกราฟของโหนดบนเส้นทางทั้งหมดจากเป้าหมายใดๆ ใน S ไปยังเป้าหมายใดๆ ใน E

กราฟผลลัพธ์จะถูกเรียงลำดับตามความสัมพันธ์ในการพึ่งพา ดูรายละเอียดเพิ่มเติมได้ที่ส่วนลำดับกราฟ

ซอมพาธ — `somepath(S1 + S2, E)`, ผลลัพธ์ที่เป็นไปได้ 1 รายการ

การกรองชนิดเป้าหมาย: ชนิด

expr ::= kind(word, expr)

โอเปอเรเตอร์ kind(pattern, input) ใช้ตัวกรองกับชุดเป้าหมาย และทิ้งเป้าหมายที่ไม่ใช่ประเภทที่คาดไว้ พารามิเตอร์ pattern จะระบุประเภทเป้าหมายที่จะจับคู่

เช่น ประเภทของเป้าหมาย 4 รายการที่กำหนดโดยไฟล์ BUILD (สำหรับแพ็กเกจ p) ที่แสดงด้านล่างจะแสดงในตาราง

โค้ด	เป้าหมาย	ชนิด
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", )	`//p:a`	กฎ Genrule
	`//p:a.in`	ไฟล์ต้นฉบับ
	`//p:a.out`	ไฟล์ที่สร้างขึ้น
	`//p:BUILD`	ไฟล์ต้นฉบับ

ดังนั้น kind("cc_.* rule", foo/...) จะประเมินชุดของ cc_library, cc_binary, ฯลฯ เป้าหมายกฎทั้งหมดภายใต้ foo และ kind("source file", deps(//foo)) จะประเมินชุดของไฟล์ต้นทางทั้งหมดเมื่อปิดทรัพยากร Dependency ของเป้าหมาย //foo แบบทางอ้อม

มักต้องมีเครื่องหมายคำพูดของอาร์กิวเมนต์ pattern เนื่องจากโปรแกรมแยกวิเคราะห์ไม่ถือว่าเป็นคำของนิพจน์ทั่วไปจำนวนมาก เช่น source file และ .*_test

เมื่อจับคู่กับ package group เป้าหมายที่ลงท้ายด้วย :all อาจไม่แสดงผลลัพธ์ใดๆ โปรดใช้ :all-targets แทน

การกรองชื่อเป้าหมาย: ตัวกรอง

expr ::= filter(word, expr)

โอเปอเรเตอร์ filter(pattern, input) ใช้ตัวกรองกับชุดเป้าหมาย และทิ้งเป้าหมายที่ป้ายกำกับ (ในรูปแบบสัมบูรณ์) ไม่ตรงกับรูปแบบ โดยประเมินเป็นกลุ่มย่อยของอินพุต

อาร์กิวเมนต์แรก pattern คือคำที่มีนิพจน์ทั่วไปทับชื่อเป้าหมาย นิพจน์ filter จะประเมินชุดที่มีเป้าหมายทั้งหมด x โดยที่ x เป็นสมาชิกของชุด input และป้ายกำกับ (ในรูปแบบสัมบูรณ์ เช่น //foo:bar) ของ x มีการจับคู่ (ไม่เชื่อมโยง) สำหรับนิพจน์ทั่วไป pattern เนื่องจากชื่อเป้าหมายทั้งหมดขึ้นต้นด้วย // จึงอาจใช้แทน Anchor ของนิพจน์ทั่วไป ^ ได้

โอเปอเรเตอร์นี้มักมอบทางเลือกที่รวดเร็วและมีประสิทธิภาพมากกว่าโอเปอเรเตอร์ intersect ตัวอย่างเช่น หากต้องการดูทรัพยากร Dependency ทั้งหมด bar ของเป้าหมาย //foo:foo อาจมีผู้ประเมิน

deps(//foo) intersect //bar/...

อย่างไรก็ตาม คำสั่งนี้ต้องมีการแยกวิเคราะห์ไฟล์ BUILD ทั้งหมดในโครงสร้าง bar ซึ่งจะช้าและมีแนวโน้มจะเกิดข้อผิดพลาดในไฟล์ BUILD ที่ไม่เกี่ยวข้อง อีกทางเลือกหนึ่งคือ

filter(//bar, deps(//foo))

ซึ่งจะคำนวณชุดทรัพยากร Dependency ของ //foo ก่อน แล้วจึงกรองเฉพาะเป้าหมายที่ตรงกับรูปแบบที่ระบุ ส่วนคำอื่นๆ คือเป้าหมายที่มีชื่อที่มี //bar เป็นสตริงย่อย

การใช้งานโอเปอเรเตอร์ filter(pattern, expr) โดยทั่วไปอีกอย่างคือการกรองไฟล์ที่เจาะจงตามชื่อหรือนามสกุล ตัวอย่างเช่น

filter("\.cc$", deps(//foo))

จะแสดงรายการของไฟล์ .cc ทั้งหมดที่ใช้ในการสร้าง //foo

การกรองแอตทริบิวต์ของกฎ: attr

expr ::= attr(word, word, expr)

โอเปอเรเตอร์ attr(name, pattern, input) ใช้ตัวกรองกับชุดเป้าหมาย และทิ้งเป้าหมายที่ไม่ใช่กฎ เป้าหมายกฎที่ไม่ได้กำหนดแอตทริบิวต์ name หรือเป้าหมายกฎที่ค่าแอตทริบิวต์ไม่ตรงกับนิพจน์ทั่วไป pattern ที่ระบุ โดยจะประเมินอินพุตชุดย่อย

อาร์กิวเมนต์แรก name คือชื่อของแอตทริบิวต์กฎที่ควรจับคู่กับรูปแบบนิพจน์ทั่วไปที่ระบุ อาร์กิวเมนต์ที่ 2 pattern คือนิพจน์ทั่วไปที่อยู่เหนือค่าแอตทริบิวต์ นิพจน์ attr จะประเมินชุดที่มีเป้าหมายทั้งหมด x โดยที่ x เป็นสมาชิกของชุด input เป็นกฎที่มีแอตทริบิวต์ที่กำหนดไว้ name และค่าแอตทริบิวต์มีการจับคู่ที่ตรงกัน (ไม่เชื่อมโยง) สำหรับนิพจน์ทั่วไป pattern หาก name เป็นแอตทริบิวต์ที่ไม่บังคับและกฎไม่ได้ระบุไว้อย่างชัดแจ้ง ระบบจะใช้ค่าแอตทริบิวต์เริ่มต้นเพื่อเปรียบเทียบ ตัวอย่างเช่น

attr(linkshared, 0, deps(//foo))

จะเลือกทรัพยากร Dependency ทั้งหมด //foo รายการที่ได้รับอนุญาตให้มีแอตทริบิวต์ "ลิงก์ที่แชร์" (เช่น กฎ cc_binary) และตั้งค่าเป็น 0 อย่างชัดแจ้ง หรือไม่ตั้งค่าเลย แต่ค่าเริ่มต้นจะเป็น 0 (เช่น สำหรับกฎ cc_binary)

แอตทริบิวต์ประเภทรายการ (เช่น srcs, data ฯลฯ) จะแปลงเป็นสตริงในรูปแบบ [value<sub>1</sub>, ..., value<sub>n</sub>] โดยเริ่มต้นด้วยวงเล็บ [ ลงท้ายด้วยวงเล็บ ] และใช้ "," (จุลภาค, เว้นวรรค) เพื่อคั่นหลายค่า ป้ายกำกับจะแปลงเป็นสตริงโดยใช้รูปแบบสัมบูรณ์ของป้ายกำกับ เช่น แอตทริบิวต์ deps=[":foo", "//otherpkg:bar", "wiz"] จะแปลงเป็นสตริง [//thispkg:foo, //otherpkg:bar, //thispkg:wiz] โดยวงเล็บจะแสดงเสมอ ดังนั้นรายการที่ว่างเปล่าจะใช้ค่าสตริง [] เพื่อการจับคู่ ตัวอย่างเช่น

attr("srcs", "\[\]", deps(//foo))

จะเลือกกฎทั้งหมดในทรัพยากร Dependency //foo ที่มีแอตทริบิวต์ srcs ว่าง

attr("data", ".{3,}", deps(//foo))

จะเลือกกฎทั้งหมดในทรัพยากร Dependency ของ //foo ที่ระบุอย่างน้อย 1 ค่าในแอตทริบิวต์ data (ทุกป้ายกำกับมีความยาวอย่างน้อย 3 อักขระเนื่องจาก // และ :)

หากต้องการเลือกกฎทั้งหมดในทรัพยากร Dependency //foo ที่มี value เฉพาะในแอตทริบิวต์ list-type ให้ใช้

attr("tags", "[\[ ]value[,\]]", deps(//foo))

ซึ่งทำได้เนื่องจากอักขระที่อยู่ก่อน value จะเป็น [ หรือการเว้นวรรค และอักขระที่ตามหลัง value จะเป็นเครื่องหมายจุลภาคหรือ ]

การกรองระดับการเข้าถึงกฎ: มองเห็นได้

expr ::= visible(expr, expr)

โอเปอเรเตอร์ visible(predicate, input) ใช้ตัวกรองกับชุดเป้าหมาย และทิ้งเป้าหมายโดยไม่มีระดับการเข้าถึงที่จำเป็น

อาร์กิวเมนต์ predicate แรกคือชุดของเป้าหมายที่ต้องมองเห็นเป้าหมายทั้งหมดในเอาต์พุต นิพจน์ visible จะประเมินชุดที่มีเป้าหมายทั้งหมด x โดยที่ x เป็นสมาชิกของชุด input และสำหรับเป้าหมายทั้งหมด y ใน predicate x จะปรากฏแก่ y เช่น

visible(//foo, //bar:*)

จะเลือกเป้าหมายทั้งหมดในแพ็กเกจ //bar ที่ //foo พึ่งพาได้โดยไม่ละเมิดข้อจำกัดระดับการเข้าถึง

การประเมินแอตทริบิวต์กฎสำหรับป้ายกำกับประเภท: ป้ายกำกับ

expr ::= labels(word, expr)

โอเปอเรเตอร์ labels(attr_name, inputs) จะแสดงผลชุดของเป้าหมายที่ระบุในแอตทริบิวต์ attr_name ของประเภท "ป้ายกำกับ" หรือ "รายการป้ายกำกับ" ในกฎบางกฎในชุด inputs

ตัวอย่างเช่น labels(srcs, //foo) จะแสดงผลชุดของเป้าหมายที่ปรากฏในแอตทริบิวต์ srcs ของกฎ //foo หากมีกฎหลายข้อที่มีแอตทริบิวต์ srcs ในชุด inputs ระบบจะแสดงผลการรวมของ srcs

ขยายและกรอง test_suites: การทดสอบ

expr ::= tests(expr)

โอเปอเรเตอร์ tests(x) จะแสดงผลชุดกฎการทดสอบทั้งหมดในชุด x, ขยายกฎ test_suite ไปยังชุดการทดสอบเดี่ยวที่อ้างอิงถึงและใช้การกรองโดย tag และ size

โดยค่าเริ่มต้น การประเมินการค้นหาจะไม่สนใจเป้าหมายที่ไม่ใช่การทดสอบในกฎ test_suite ทั้งหมด ซึ่งอาจเปลี่ยนเป็นข้อผิดพลาดได้โดยใช้ตัวเลือก --strict_test_suite

ตัวอย่างเช่น คำค้นหา kind(test, foo:*) จะแสดงกฎ *_test และ test_suite ทั้งหมดในแพ็กเกจ foo ผลลัพธ์ทั้งหมดมาจากสมาชิกของแพ็กเกจ foo (ตามคำจำกัดความ) ในทางตรงกันข้าม คำค้นหา tests(foo:*) จะแสดงผลการทดสอบแต่ละรายการทั้งหมดที่จะดำเนินการโดย bazel test foo:* ซึ่งอาจรวมถึงการทดสอบที่เป็นของแพ็กเกจอื่นๆ ที่มีการอ้างอิงผ่านกฎ test_suite โดยตรงหรือโดยอ้อม

ไฟล์คำจำกัดความของแพ็กเกจ: ไฟล์บิลด์

expr ::= buildfiles(expr)

โอเปอเรเตอร์ buildfiles(x) จะแสดงผลชุดของไฟล์ที่ระบุแพ็กเกจของแต่ละเป้าหมายในชุด x กล่าวคือ ไฟล์ BUILD ของแต่ละแพ็กเกจ รวมถึงไฟล์ .bzl ทั้งหมดที่ปลายทางดังกล่าวอ้างอิงผ่าน load โปรดทราบว่าการดำเนินการนี้จะแสดงไฟล์ BUILD ของแพ็กเกจที่มีไฟล์ load เหล่านี้ด้วย

โดยปกติแล้วโอเปอเรเตอร์นี้จะใช้ในการกำหนดไฟล์หรือแพ็กเกจที่จำเป็นต่อการสร้างเป้าหมายที่ระบุ โดยมักจะใช้ร่วมกับตัวเลือก --output package ด้านล่าง) ตัวอย่างเช่น

bazel query 'buildfiles(deps(//foo))' --output package

จะแสดงผลชุดของแพ็กเกจทั้งหมดที่ //foo ขึ้นอยู่กับแบบสกรรม

คำเตือน: Bazel แสดงแทนไฟล์ .bzl เป้าหมาย .bzl ที่ .bzl ตัวอย่าง (ตัวอย่าง .bzl คือไฟล์ที่ .bzl สร้างไว้ (ตัวอย่าง .bzl ที่เกี่ยวข้อง) จะไม่มีไฟล์เป้าหมาย .bzl ที่เกี่ยวข้องbuildfilesa/b.bzl//a:b.bzl ดังนั้น buildfiles จึงเขียนได้ไม่ดีกับโอเปอเรเตอร์การค้นหาอื่นๆ และผลลัพธ์อาจทำให้เข้าใจผิดได้หากมีการจัดรูปแบบอย่างมีโครงสร้าง เช่น [--output=xml](#output-xml)

ไฟล์การกำหนดแพ็กเกจ: rbuildfiles

expr ::= rbuildfiles(word, ...)

โอเปอเรเตอร์ rbuildfiles จะรับรายการส่วนย่อยของเส้นทางซึ่งคั่นด้วยคอมมาและแสดงผลชุดไฟล์ BUILD ซึ่งอาศัยส่วนย่อยของเส้นทางเหล่านี้แบบสับเปลี่ยน เช่น หาก //foo เป็นแพ็กเกจ rbuildfiles(foo/BUILD) จะแสดงผลเป้าหมาย //foo:BUILD หากไฟล์ foo/BUILD มี load('//bar:file.bzl'... อยู่ด้วย rbuildfiles(bar/file.bzl) จะแสดงผลเป้าหมาย //foo:BUILD รวมถึงเป้าหมายสำหรับไฟล์ BUILD อื่นๆ ที่โหลด //bar:file.bzl

ขอบเขตของโอเปอเรเตอร์ rbuildfiles คือจักรวาลที่ระบุโดย Flag --universe_scope ไฟล์ที่ไม่เป็นไปตามไฟล์ BUILD และ .bzl โดยตรงจะไม่ส่งผลต่อผลการค้นหา เช่น ระบบจะไม่สนใจไฟล์ต้นฉบับ (เช่น foo.cc) แม้ว่าจะมีการกล่าวถึงไฟล์ BUILD อย่างชัดแจ้งก็ตาม อย่างไรก็ตาม ระบบจะยึดตามลิงก์สัญลักษณ์ ดังนั้นหาก foo/BUILD เป็นลิงก์สัญลักษณ์ไปยัง bar/BUILD แล้ว rbuildfiles(bar/BUILD) ก็จะรวม //foo:BUILD ไว้ในผลลัพธ์ด้วย

โอเปอเรเตอร์ rbuildfiles เกือบจะมีค่าผกผันกับโอเปอเรเตอร์ buildfiles อย่างไรก็ตาม การกลับด้านจริยธรรมนี้ยึดมั่นในทิศทางเดียวมากกว่า กล่าวคือ เอาต์พุตของ rbuildfiles จะเหมือนกับอินพุตของ buildfiles เอาต์พุตแรกจะมีเป้าหมายไฟล์เพียง BUILD รายการในแพ็กเกจ และผลลัพธ์หลังอาจมีเป้าหมายดังกล่าว ในอีกทิศทางหนึ่ง การสื่อสารจะอ่อนกว่า เอาต์พุตของโอเปอเรเตอร์ buildfiles คือเป้าหมายที่ตรงกับแพ็กเกจทั้งหมดและbzl ไฟล์ที่จำเป็นต่ออินพุตที่ระบุ อย่างไรก็ตาม อินพุตของโอเปอเรเตอร์ rbuildfiles ไม่ใช่เป้าหมายเหล่านั้น แต่เป็นส่วนย่อยของเส้นทางที่สอดคล้องกับเป้าหมายเหล่านั้น

ไฟล์การกำหนดแพ็กเกจ: ไฟล์โหลด

expr ::= loadfiles(expr)

โอเปอเรเตอร์ loadfiles(x) จะแสดงผลชุดของไฟล์ Starlark ที่จำเป็นต่อการโหลดแพ็กเกจของเป้าหมายแต่ละรายการในชุด x กล่าวคือ สำหรับแต่ละแพ็กเกจ ระบบจะแสดงไฟล์ .bzl ที่อ้างอิงจากไฟล์ BUILD ของแพ็กเกจ

รูปแบบเอาต์พุต

bazel query จะสร้างกราฟ คุณระบุเนื้อหา รูปแบบ และลำดับที่ bazel query แสดงกราฟนี้โดยใช้ตัวเลือกบรรทัดคำสั่ง --output

เมื่อเรียกใช้ Sky Query จะอนุญาตเฉพาะรูปแบบเอาต์พุตที่เข้ากันได้กับเอาต์พุตที่ไม่เรียงลำดับเท่านั้น กล่าวอย่างเจาะจงคือ เราไม่อนุญาตรูปแบบเอาต์พุต graph, minrank และ maxrank

รูปแบบเอาต์พุตบางรูปแบบยอมรับตัวเลือกเพิ่มเติม ชื่อของตัวเลือกเอาต์พุตแต่ละรายการจะมีคำนำหน้าด้วยรูปแบบเอาต์พุตที่ใช้ ดังนั้น --graph:factored จึงมีผลเฉพาะเมื่อมีการใช้ --output=graph เท่านั้น และจะไม่มีผลหากใช้รูปแบบเอาต์พุตอื่นที่ไม่ใช่ graph ในทำนองเดียวกัน --xml:line_numbers จะมีผลก็ต่อเมื่อใช้ --output=xml เท่านั้น

เกี่ยวกับลำดับของผลลัพธ์

แม้ว่านิพจน์ข้อความค้นหาจะเป็นไปตาม "กฎการรักษาลำดับกราฟ" เสมอ แต่การนำเสนอผลลัพธ์อาจทำได้ในลักษณะเรียงลำดับขึ้นหรือไม่เรียงลำดับ ซึ่งไม่ส่งผลต่อเป้าหมายในชุดผลลัพธ์หรือวิธีคำนวณคำค้นหา ซึ่งส่งผลเฉพาะกับวิธีการพิมพ์ผลลัพธ์ไปยัง Stdout นอกจากนี้ โหนดที่เทียบเท่ากันในลำดับทรัพยากร Dependency อาจมีหรือไม่ได้เรียงลำดับตามตัวอักษร คุณใช้แฟล็ก --order_output เพื่อควบคุมลักษณะการทำงานนี้ได้ (แฟล็ก --[no]order_results มีฟังก์ชันการทำงานเพียงบางส่วนของ Flag --order_output และเลิกใช้งานแล้ว)

ค่าเริ่มต้นของแฟล็กนี้คือ auto ซึ่งพิมพ์ผลลัพธ์เป็นลำดับคำศัพท์ แต่เมื่อใช้ somepath(a,b) ผลลัพธ์จะพิมพ์ตามลำดับ deps แทน

เมื่อแฟล็กนี้คือ no และ --output เป็นหนึ่งใน build, label, label_kind, location, package, proto หรือ xml ระบบจะพิมพ์เอาต์พุตตามลำดับที่กำหนดเอง โดยทั่วไปตัวเลือกนี้จะเป็นตัวเลือกที่เร็วที่สุด แต่เมื่อ --output เป็น graph, minrank หรือ maxrank (รูปแบบเหล่านี้) จะไม่รองรับรูปแบบดังกล่าว Bazel จะพิมพ์ผลลัพธ์ที่เรียงลำดับตามการเรียงลำดับหรืออันดับของทรัพยากร Dependency เสมอ

เมื่อแฟล็กนี้มีค่าเป็น deps Bazel จะพิมพ์ผลลัพธ์ตามลำดับโทโพโลยี ซึ่งก็คือการขึ้นต่อกันก่อน อย่างไรก็ตาม โหนดที่ไม่ได้เรียงลำดับตามลำดับของทรัพยากร Dependency (เนื่องจากไม่มีเส้นทางจากหนึ่งไปยังอีกที่หนึ่ง) จะพิมพ์ในลำดับใดก็ได้

เมื่อแฟล็กนี้มีค่าเป็น full Bazel จะพิมพ์โหนดตามลำดับที่กำหนดโดยสมบูรณ์ (ทั้งหมด) ขั้นแรก โหนดทั้งหมดจัดเรียงตามตัวอักษร จากนั้นแต่ละโหนดในรายการจะใช้เป็นจุดเริ่มต้นของการค้นหาแรกหลังการเรียงลำดับ สุดท้าย โหนดจะถูกพิมพ์กลับกัน ของลำดับการเข้าชม

โหนดการพิมพ์ตามลำดับนี้อาจทำงานได้ช้าลง คุณจึงควรใช้โหนดดังกล่าวเมื่อการกำหนดเป็นโหนดสำคัญเท่านั้น

พิมพ์รูปแบบแหล่งที่มาของเป้าหมายตามที่จะปรากฏใน BUILD

--output build

เมื่อใช้ตัวเลือกนี้ การนำเสนอของแต่ละเป้าหมายจะเสมือนกับว่าเป้าหมายนั้นเขียนด้วยลายมือในภาษาของ BUILD ตัวแปรและการเรียกใช้ฟังก์ชันทั้งหมด (เช่น glob, มาโคร) จะถูกขยายออก ซึ่งมีประโยชน์ในการดูผลของมาโคร Starlark นอกจากนี้ กฎที่มีผลแต่ละกฎจะรายงานค่า generator_name และ/หรือ generator_function) ซึ่งเป็นชื่อของมาโครที่ได้รับการประเมินเพื่อสร้างกฎที่มีประสิทธิภาพ

แม้ว่าเอาต์พุตจะใช้ไวยากรณ์เดียวกันกับไฟล์ BUILD แต่ไม่รับประกันว่าจะสร้างไฟล์ BUILD ที่ถูกต้อง

พิมพ์ป้ายกำกับของแต่ละเป้าหมาย

--output label

เมื่อใช้ตัวเลือกนี้ ชุดชื่อ (หรือป้ายกำกับ) ของแต่ละเป้าหมายในกราฟผลลัพธ์จะได้รับการพิมพ์ 1 ป้ายกำกับต่อบรรทัด ตามลำดับโทโพโลยี (เว้นแต่จะระบุ --noorder_results โปรดดูหมายเหตุเกี่ยวกับการจัดลำดับผลลัพธ์) (การจัดลำดับโทโพโลยีคือการที่โหนดกราฟปรากฏก่อนโหนดที่สืบทอดมาทั้งหมด) แน่นอนว่ามีการจัดลำดับด้านโทโพโลยีที่เป็นไปได้หลายแบบของกราฟ (การย้อนลำดับกลับเป็นเพียงลำดับเดียว) โดยจะเลือกแบบใดก็ได้โดยไม่ได้ระบุ

เมื่อพิมพ์เอาต์พุตของคำค้นหา somepath ลำดับที่พิมพ์โหนดจะเป็นลำดับของเส้นทาง

ข้อควรระวัง: ในบางกรณีอาจมีเป้าหมายที่ต่างกัน 2 รายการซึ่งมีป้ายกํากับเดียวกัน เช่น กฎ sh_binary และไฟล์ srcs เพียงอย่างเดียว (โดยนัย) อาจเรียกว่า foo.sh หากผลการค้นหามีเป้าหมายทั้ง 2 รายการนี้ เอาต์พุต (ในรูปแบบ label) จะดูเหมือนมีสำเนาที่ซ้ำกัน เมื่อใช้รูปแบบ label_kind (ดูด้านล่าง) ความแตกต่างจะชัดเจนขึ้น เพราะเป้าหมาย 2 รายการมีชื่อเดียวกัน แต่มีประเภทหนึ่งเป็น sh_binary rule และอีกเป้าหมายคือ source file

พิมพ์ป้ายกำกับและชนิดของเป้าหมายแต่ละรายการ

--output label_kind

เช่นเดียวกับ label รูปแบบเอาต์พุตนี้จะพิมพ์ป้ายกำกับของเป้าหมายแต่ละรายการในกราฟผลลัพธ์โดยเรียงตามลำดับด้านโทโพโลยี แต่อยู่ก่อนป้ายกำกับด้วย ประเภท ของเป้าหมาย

พิมพ์ป้ายกำกับของเป้าหมายแต่ละรายการตามลำดับอันดับ

--output minrank --output maxrank

เช่นเดียวกับ label รูปแบบเอาต์พุต minrank และ maxrank จะพิมพ์ป้ายกำกับของแต่ละเป้าหมายในกราฟผลลัพธ์ แต่แทนที่จะปรากฎตามลำดับโทโพโลยี แต่จะปรากฏในลำดับอันดับที่นำหน้าด้วยหมายเลขอันดับ ซึ่งจะไม่ได้รับผลกระทบจากการเรียงลำดับผลลัพธ์ --[no]order_results Flag (ดูหมายเหตุเกี่ยวกับการจัดลำดับผลลัพธ์)

รูปแบบนี้มี 2 ตัวแปร ได้แก่ minrank จะจัดอันดับแต่ละโหนดตามความยาวของเส้นทางที่สั้นที่สุดจากโหนดรากไปถึงโหนดนั้น โหนด "ราก" (ที่ไม่มีขอบขาเข้า) อยู่ในอันดับ 0 โหนดสืบทอดมาจากอันดับ 1 เป็นต้น (และเช่นเคย จุดขอบจะชี้จากเป้าหมายไปยังสิ่งที่ต้องมี ซึ่งก็คือเป้าหมายที่มันขึ้นอยู่กับ)

maxrank จะจัดอันดับแต่ละโหนดตามความยาวของเส้นทางที่ยาวที่สุดจากโหนดรากถึงโหนดนั้น ขอย้ำอีกครั้งว่า "ราก" มีอันดับ 0 ส่วนโหนดอื่นๆ ทั้งหมดมีอันดับที่มากกว่า 1 อันดับสูงสุดของโหนดก่อนหน้า

โหนดทั้งหมดในวงจรจะถือว่ามีอันดับเท่ากัน (กราฟส่วนใหญ่แสดงแบบวนซ้ำ แต่เป็นวงจรที่เกิดขึ้นได้ง่ายๆ เพราะไฟล์ BUILD มีรอบที่ผิดพลาด)

รูปแบบเอาต์พุตเหล่านี้มีประโยชน์ในการค้นหาว่ากราฟลึกเพียงใด หากใช้ผลลัพธ์ของการค้นหา deps(x), rdeps(x) หรือ allpaths ตัวเลขอันดับจะเท่ากับความยาวของเส้นทางที่สั้นที่สุด (โดยมี minrank) หรือยาวที่สุด (โดยมี maxrank) จาก x ไปยังโหนดในอันดับนั้น maxrank จะใช้เพื่อกำหนดลำดับขั้นตอนบิลด์ที่ยาวที่สุดที่จำเป็นต่อการสร้างเป้าหมาย

เช่น กราฟทางด้านซ้ายจะแสดงผลเอาต์พุตทางด้านขวาเมื่อมีการระบุ --output minrank และ --output maxrank ตามลำดับ

      minrank

      0 //c:c
      1 //b:b
      1 //a:a
      2 //b:b.cc
      2 //a:a.cc

      maxrank

      0 //c:c
      1 //b:b
      2 //a:a
      2 //b:b.cc
      3 //a:a.cc

พิมพ์สถานที่ตั้งของแต่ละเป้าหมาย

--output location

เช่นเดียวกับ label_kind ตัวเลือกนี้จะพิมพ์ประเภทและป้ายกำกับของเป้าหมายแต่ละรายการในผลลัพธ์ แต่นำหน้าด้วยสตริงที่อธิบายตำแหน่งของเป้าหมายนั้นเป็นชื่อไฟล์และหมายเลขบรรทัด รูปแบบจะคล้ายกับเอาต์พุตของ grep ดังนั้น เครื่องมือที่สามารถแยกวิเคราะห์รายการหลัง (เช่น Emacs หรือ vi) ยังสามารถใช้ผลลัพธ์การค้นหาเพื่อเลื่อนดูการจับคู่ที่ตรงกัน ทำให้สามารถใช้เครื่องมือ Query ของ Bazel เป็น "grep for BUILD files" แบบ Dependency-graph-Aware ได้

ข้อมูลตำแหน่งจะแตกต่างกันไปตามประเภทเป้าหมาย (ดูโอเปอเรเตอร์ kind) สำหรับกฎ ระบบจะพิมพ์ตำแหน่งการประกาศของกฎภายในไฟล์ BUILD สำหรับไฟล์ต้นฉบับ ระบบจะพิมพ์ตำแหน่งบรรทัดที่ 1 ของไฟล์จริง สำหรับไฟล์ที่สร้างขึ้น ระบบจะพิมพ์ตำแหน่งของกฎที่สร้าง (เครื่องมือ Query มีข้อมูลไม่เพียงพอที่จะค้นหาตำแหน่งที่แท้จริงของไฟล์ที่สร้างขึ้น และไม่ว่าในกรณีใดก็ตาม เครื่องมือนี้อาจไม่มีอยู่หากยังไม่มีการดำเนินการสร้าง)

พิมพ์ชุดแพ็กเกจ

--output package

ตัวเลือกนี้จะพิมพ์ชื่อแพ็กเกจทั้งหมดที่มีเป้าหมายบางรายการในชุดผลลัพธ์อยู่ ชื่อจะพิมพ์ตามลำดับตัวอักษร ไม่รวมคำซ้ำ อย่างเป็นทางการ นี่คือการคาดการณ์จากชุดของป้ายกำกับ (แพ็กเกจ เป้าหมาย) ไปยังแพ็กเกจ

แพ็กเกจในที่เก็บภายนอกจัดรูปแบบเป็น @repo//foo/bar ในขณะที่แพ็กเกจในที่เก็บหลักจะมีการจัดรูปแบบเป็น foo/bar

คุณใช้ตัวเลือกเอาต์พุตนี้ร่วมกับการค้นหา deps(...) เพื่อค้นหาชุดแพ็กเกจที่ต้องชำระเงินเพื่อสร้างชุดเป้าหมายที่กำหนดได้

แสดงกราฟของผลลัพธ์

--output graph

ตัวเลือกนี้ทำให้ผลการค้นหาพิมพ์เป็นกราฟโดยตรงในรูปแบบ GraphViz ยอดนิยมของ AT&T โดยปกติแล้วระบบจะบันทึกผลลัพธ์ลงในไฟล์ เช่น .png หรือ .svg (หากไม่ได้ติดตั้งโปรแกรม dot บนเวิร์กสเตชัน คุณจะติดตั้งโปรแกรมได้โดยใช้คำสั่ง sudo apt-get install graphviz) ดูการเรียกใช้ตัวอย่างในส่วนตัวอย่างด้านล่าง

รูปแบบเอาต์พุตนี้มีประโยชน์อย่างยิ่งสำหรับการค้นหา allpaths, deps หรือ rdeps ซึ่งผลลัพธ์จะมีชุดเส้นทาง ซึ่งมองไม่เห็นได้อย่างง่ายดายเมื่อแสดงผลในรูปแบบเชิงเส้น เช่น --output label

กราฟจะแสดงผลในรูปแบบแยกตัวประกอบโดยค่าเริ่มต้น กล่าวคือ โหนดที่เท่าเทียมกันในตำแหน่งโทโพโลยีจะรวมกันเป็นโหนดเดียวที่มีป้ายกำกับหลายป้าย ซึ่งจะทำให้กราฟกะทัดรัดและอ่านได้ง่ายขึ้น เนื่องจากกราฟผลลัพธ์โดยทั่วไปมีรูปแบบที่ซ้ำกันมาก เช่น กฎ java_library อาจขึ้นอยู่กับไฟล์ต้นฉบับของ Java หลายร้อยไฟล์ซึ่งทั้งหมดสร้างขึ้นด้วย genrule เดียวกัน ในกราฟแบบประกอบ ไฟล์เหล่านี้ทั้งหมดจะแทนด้วยโหนดเดียว ลักษณะการทำงานนี้อาจปิดใช้ ด้วยตัวเลือก --nograph:factored

`--graph:node_limit n`

ตัวเลือกนี้จะระบุความยาวสูงสุดของสตริงป้ายกำกับสำหรับโหนดกราฟในเอาต์พุต ป้ายกำกับที่ยาวจะถูกตัดให้สั้นลง ส่วน -1 จะปิดใช้การตัดข้อความ ป้ายกำกับโหนดอาจยาวมากเนื่องจากรูปแบบตัวประกอบที่มักจะพิมพ์กราฟ GraphViz จะจัดการกับป้ายกำกับที่ยาวเกิน 1, 024 อักขระซึ่งเป็นค่าเริ่มต้นของตัวเลือกนี้ไม่ได้ ตัวเลือกนี้จะไม่มีผล เว้นแต่จะใช้ --output=graph

`--[no]graph:factored`

โดยค่าเริ่มต้น กราฟจะแสดงในรูปแบบแยกตัวประกอบตามที่อธิบายไว้ด้านบน เมื่อระบุ --nograph:factored ระบบจะพิมพ์กราฟโดยไม่มีการแยกตัวประกอบ ซึ่งทำให้การแสดงข้อมูลผ่านภาพโดยใช้ GraphViz ใช้งานได้จริง แต่รูปแบบที่ง่ายกว่าอาจทำให้เครื่องมืออื่นๆ (เช่น grep) ประมวลผลได้ง่ายขึ้น ตัวเลือกนี้ไม่มีผลเว้นแต่จะมีการใช้ --output=graph

XML

--output xml

ตัวเลือกนี้จะทำให้เป้าหมายที่ได้พิมพ์ในรูปแบบ XML เอาต์พุตจะเริ่มต้นด้วยส่วนหัว XML เช่นนี้

  <?xml version="1.0" encoding="UTF-8"?>
  <query version="2">

และต่อด้วยเอลิเมนต์ XML สำหรับแต่ละเป้าหมายในกราฟผลลัพธ์ ตามลำดับ (นอกเสียจากจะมีการขอผลลัพธ์ที่ไม่เรียงลำดับ) และปิดท้ายด้วยการสิ้นสุด

</query>

ส่งรายการแบบง่ายสำหรับเป้าหมายประเภท file ต่อไปนี้

  <source-file name='//foo:foo_main.cc' .../>
  <generated-file name='//foo:libfoo.so' .../>

แต่สำหรับกฎแล้ว XML จะมีโครงสร้างและมีคำจำกัดความของแอตทริบิวต์ทั้งหมดของกฎ ซึ่งรวมถึงแอตทริบิวต์ที่ไม่ได้ระบุค่าไว้อย่างชัดเจนในไฟล์ BUILD ของกฎ

นอกจากนี้ ผลลัพธ์จะมีองค์ประกอบ rule-input และ rule-output เพื่อให้สร้างโทโพโลยีของกราฟการขึ้นต่อกันใหม่ได้โดยไม่ต้องทราบว่า ตัวอย่างเช่น องค์ประกอบของแอตทริบิวต์ srcs เป็นทรัพยากร Dependency แบบส่งต่อ (ข้อกำหนดเบื้องต้น) และเนื้อหาของแอตทริบิวต์ outs เป็นทรัพยากร Dependency แบบย้อนกลับ (ผู้บริโภค)

องค์ประกอบ rule-input สำหรับทรัพยากร Dependency โดยนัยจะถูกระงับหากระบุ --noimplicit_deps ไว้

  <rule class='cc_binary rule' name='//foo:foo' ...>
    <list name='srcs'>
      <label value='//foo:foo_main.cc'/>
      <label value='//foo:bar.cc'/>
      ...
    </list>
    <list name='deps'>
      <label value='//common:common'/>
      <label value='//collections:collections'/>
      ...
    </list>
    <list name='data'>
      ...
    </list>
    <int name='linkstatic' value='0'/>
    <int name='linkshared' value='0'/>
    <list name='licenses'/>
    <list name='distribs'>
      <distribution value="INTERNAL" />
    </list>
    <rule-input name="//common:common" />
    <rule-input name="//collections:collections" />
    <rule-input name="//foo:foo_main.cc" />
    <rule-input name="//foo:bar.cc" />
    ...
  </rule>

องค์ประกอบ XML ทุกรายการของเป้าหมายจะมีแอตทริบิวต์ name ซึ่งมีค่าเป็นป้ายกำกับของเป้าหมาย และแอตทริบิวต์ location ซึ่งมีค่าเป็นตำแหน่งของเป้าหมายตามที่ --output location พิมพ์

`--[no]xml:line_numbers`

โดยค่าเริ่มต้น ตำแหน่งที่แสดงในเอาต์พุต XML จะมีหมายเลขบรรทัดอยู่ เมื่อระบุ --noxml:line_numbers แล้ว จะไม่มีการพิมพ์หมายเลขบรรทัด

`--[no]xml:default_values`

โดยค่าเริ่มต้น เอาต์พุต XML จะไม่รวมแอตทริบิวต์กฎที่มีค่าเป็นค่าเริ่มต้นสำหรับแอตทริบิวต์ประเภทนั้น (เช่น หากไม่ได้ระบุไว้ในไฟล์ BUILD หรือมีการระบุค่าเริ่มต้นไว้อย่างชัดแจ้ง) ตัวเลือกนี้จะทำให้ค่าแอตทริบิวต์ดังกล่าวรวมอยู่ในเอาต์พุต XML

นิพจน์ทั่วไป

นิพจน์ทั่วไปในภาษาคำค้นหาใช้ไลบรารีนิพจน์ทั่วไปของ Java เพื่อให้คุณใช้ไวยากรณ์แบบเต็มสำหรับ java.util.regex.Pattern ได้

การค้นหาด้วยที่เก็บภายนอก

หากบิลด์ขึ้นอยู่กับกฎจากที่เก็บภายนอก (ตามที่กำหนดไว้ในไฟล์ WORKSPACE) ผลการค้นหาจะรวมทรัพยากร Dependency เหล่านี้ไว้ด้วย เช่น หาก //foo:bar ขึ้นอยู่กับ //external:some-lib และ //external:some-lib เชื่อมโยงกับ @other-repo//baz:lib แล้ว bazel query 'deps(//foo:bar)' จะแสดงทั้ง @other-repo//baz:lib และ //external:some-lib เป็นทรัพยากร Dependency

ที่เก็บภายนอกนั้นไม่ใช่ทรัพยากร Dependency ของบิลด์ กล่าวคือ ในตัวอย่างด้านบน //external:other-repo ไม่ใช่ทรัพยากร Dependency แต่จะค้นหาได้ในฐานะสมาชิกของแพ็กเกจ //external ได้ เช่น

  # Querying over all members of //external returns the repository.
  bazel query 'kind(http_archive, //external:*)'
  //external:other-repo

  # ...but the repository is not a dependency.
  bazel query 'kind(http_archive, deps(//foo:bar))'
  INFO: Empty results