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

รายงานปัญหา ดูแหล่งที่มา

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

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

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

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

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

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

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

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

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

ดูรายละเอียดเพิ่มเติมได้ที่การอ้างอิง 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 คีย์เวิร์ดเป็นคำที่สงวนไว้ของภาษานั้นๆ และอธิบายไว้ด้านล่าง ชุดคีย์เวิร์ดทั้งหมดคือ

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

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

    การระบุจำเป็นเมื่อเขียนสคริปต์ที่สร้างนิพจน์คำค้นหาของ 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 ที่กำหนดไว้อย่างชัดแจ้งในไฟล์ BUILD แล้ว Bazel ยังเพิ่มทรัพยากร Dependency แบบ implicit เพิ่มเติมไปยังกฎด้วย เช่น กฎ Java ทั้งหมดจะขึ้นอยู่กับ JavaBuilder โดยปริยาย ทรัพยากร Dependency โดยนัยสร้างขึ้นโดยใช้แอตทริบิวต์ที่ขึ้นต้นด้วย $ และลบล้างไม่ได้ในไฟล์ BUILD

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

เสียง

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

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

คงลำดับกราฟไว้

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

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

deps(x) union y

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

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

คำถามเกี่ยวกับ Sky

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

ฟังก์ชันพิเศษใช้ได้เฉพาะใน 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"] ดังนั้น 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 จะประเมินชุดที่มี 1 องค์ประกอบ ได้แก่ เป้าหมาย และกฎ 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 = expr1 in expr2
       | $name

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

เช่น 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/...

คุณเขียนคำค้นหาได้เหมือนกับ

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

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

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

การปิดชั่วคราวของทรัพยากร 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 รายการ
ซัมพาธ
somepath(S1 + S2, E) เป็นผลลัพธ์อื่นที่เป็นไปได้
เส้นทางทั้งหมด
allpaths(S1 + S2, E)

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

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

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

expr ::= buildfiles(expr)

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

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

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

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

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

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

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

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

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

--output label

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

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

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

--output label_kind

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

--output proto

พิมพ์เอาต์พุตการค้นหาเป็นบัฟเฟอร์โปรโตคอล QueryResult

--output streamed_proto

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

--output textproto

เช่นเดียวกับ --output proto พิมพ์บัฟเฟอร์โปรโตคอลของ QueryResult แต่ในรูปแบบข้อความ

--output streamed_jsonproto

เช่นเดียวกับ --output streamed_proto ให้พิมพ์สตรีมบัฟเฟอร์โปรโตคอล Target แต่อยู่ในรูปแบบ ndjson

--output minrank --output maxrank

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

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

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

โหนดทั้งหมดในรอบจะถือว่ามีอันดับเท่ากัน (กราฟส่วนใหญ่มีลักษณะเป็นวงจร แต่วงจรจะเกิดขึ้นเพียงเพราะไฟล์ 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" ที่รับรู้กราฟได้

ข้อมูลตำแหน่งจะแตกต่างกันไปตามประเภทเป้าหมาย (ดูโอเปอเรเตอร์ 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 ได้

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

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