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

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

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

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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

เหตุใดต้นไม้ //foo จึงอาศัย //bar/baz แสดงเส้นทาง:

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

ไลบรารี C++ ใดที่การทดสอบ foo ทั้งหมดขึ้นอยู่กับเป้าหมาย 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.
```
โปรดทราบว่าใบเสนอราคานี้เป็นส่วนเพิ่มเติมจากใบเสนอราคาที่ Shell อาจจำเป็นต้องใช้ เช่น
```
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) ของเป้าหมาย นี่เป็นประเภทข้อมูลเดียว

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

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

รอบในกราฟ Dependency

สร้างกราฟการอ้างอิงควรเป็นแบบวนซ้ำ

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

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

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

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

ความเสียง

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

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

การรักษาลำดับของกราฟ

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

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

deps(x) union y

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

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

การค้นหา Sky

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

ฟังก์ชันพิเศษเฉพาะใน SkyQuery

โหมด Query ของ Sky มีฟังก์ชันการค้นหาเพิ่มเติม 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"] ดังนั้น Bayel จะดำเนินการกับคำสั่งนี้เหมือนกับการเรียกใช้

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 ก็ต่อเมื่อพฤติกรรมของ URL นั้นเป็นสิ่งที่คุณต้องการเท่านั้น

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 เปรียบเสมือน คำ แต่มีข้อจำกัดเพิ่มเติมที่ว่าคำนี้จะเป็นตัวระบุทางกฎหมายในภาษา C Programming การอ้างอิงตัวแปรต้องมีเครื่องหมาย "$" นำหน้า

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

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

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

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

expr ::= (expr)

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

การดำเนินการเซตพีชคณิต: อินเตอร์เซกชัน ยูเนียน ผลต่างเซต

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

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

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

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

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

คุณสามารถเขียนข้อความค้นหาได้เหมือนกับ:

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

การดำเนินการ intersect (^) และ union (+) เป็นแบบสับเปลี่ยน (สมมาตร) except (-) มีความไม่สมมาตร โปรแกรมแยกวิเคราะห์จะถือว่าโอเปอเรเตอร์ทั้ง 3 รายการเป็นการเชื่อมโยงด้านซ้ายและมีลำดับความสำคัญเท่ากัน ดังนั้นคุณอาจต้องการใส่วงเล็บ ตัวอย่างเช่น สองนิพจน์แรกนี้เทียบเท่ากัน แต่นิพจน์ที่ 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 แล้ว set() ยังให้ข้อมูลเกี่ยวกับการบันทึกผลลัพธ์ของคำค้นหา 1 รายการในไฟล์ข้อความปกติ การจัดการไฟล์ข้อความนั้นโดยใช้โปรแกรมอื่น (เช่น เครื่องมือ UNIX Shell มาตรฐาน) จากนั้นจึงนำผลลัพธ์กลับเข้ามาในเครื่องมือ 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/...) คือกราฟการอ้างอิงที่รากเป็นกฎทั้งหมดในทุกแพ็กเกจภายใต้ไดเรกทอรี foo ในบริบทนี้ "dependencies" หมายถึงกฎและเป้าหมายไฟล์เท่านั้น ดังนั้นไฟล์ BUILD และ Starlark ที่จำเป็นในการสร้างเป้าหมายเหล่านี้จึงไม่ได้รวมอยู่ที่นี่ ด้วยเหตุนี้ คุณจึงควรใช้โอเปอเรเตอร์ buildfiles

ระบบจะเรียงลำดับกราฟที่ได้ตามความสัมพันธ์ของ Dependency สำหรับรายละเอียดเพิ่มเติม โปรดดูส่วนลำดับกราฟ

โอเปอเรเตอร์ 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

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

โอเปอเรเตอร์ rdeps จะยอมรับอาร์กิวเมนต์ที่ 3 ซึ่งไม่บังคับ ซึ่งเป็นเลขจำนวนเต็มที่ระบุขอบเขตบนของความลึกของการค้นหา กราฟผลลัพธ์จะรวมเฉพาะโหนดที่อยู่ภายในระยะห่างของความลึกที่ระบุจากโหนดใดก็ตามในชุดอาร์กิวเมนต์ เพื่อให้ 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 หรือไม่ก็ได้ หากค่าขาดหายไป ผลลัพธ์จะเป็นชุดเดี่ยวที่มีการเลือกเป้าหมายเพียงรายการเดียวเท่านั้น หากขนาดของชุดอาร์กิวเมนต์ 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 จะคํานวณฟังก์ชัน Identity ซึ่ง 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 ตัว ได้แก่ S ชุดของจุดเริ่มต้น และชุด E ของจุดสิ้นสุด somepath จะแสดงผลกราฟของโหนดบนเส้นทางที่กำหนดเองบางจากเป้าหมายใน S ไปยังเป้าหมายใน E allpaths จะแสดงผลกราฟของโหนดบนเส้นทางทั้งหมดจากเป้าหมายใดก็ได้ใน S ไปยังเป้าหมายใน E

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

เส้นทางบางแห่ง — `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`	กฎเกณฑ์
	`//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 ที่อนุญาตให้มีแอตทริบิวต์ linkshared (เช่น กฎ 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 หนึ่งๆ ในแอตทริบิวต์ประเภทรายการ ให้ใช้

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

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

expr ::= buildfiles(expr)

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

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

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

จะแสดงชุดของแพ็กเกจทั้งหมดที่ //foo เกี่ยวข้องกัน

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

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

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

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

ขอบเขตของโอเปอเรเตอร์ rbuildfiles คือจักรวาลที่ระบุโดยแฟล็ก --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 มีฟังก์ชันการทำงานบางส่วนของแฟล็ก --order_output และเลิกใช้งานแล้ว)

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

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

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

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

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

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

--output build

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

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

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

--output label

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

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

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

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

--output label_kind

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

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

--output minrank --output maxrank

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

รูปแบบนี้จะมี 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

ตัวเลือกนี้จะทำให้การพิมพ์ผลการค้นหาเป็นกราฟโดยตรงในรูปแบบ AT&T GraphViz ยอดนิยม โดยปกติแล้ว ผลลัพธ์จะบันทึกไปยังไฟล์ เช่น .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