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

รายงานปัญหา ดูแหล่งที่มา รุ่น Nightly · 7.4 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ดูกรณีการใช้งานจริงได้ที่วิธีการค้นหาด้วย Bazel

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

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

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

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

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

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

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

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

ตัวอย่าง

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

Why does the //foo tree depend on //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 คีย์เวิร์ดคือคำที่สงวนไว้ของภาษานั้นๆ ซึ่งจะอธิบายแต่ละคำด้านล่างนี้ คีย์เวิร์ดทั้งหมดมีดังนี้

  • คํา เช่น "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.
    

    โปรดทราบว่าการอ้างอิงนี้นอกเหนือจากการอ้างอิงใดๆ ที่เชลล์ของคุณอาจกำหนด เช่น

    bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.

    เมื่อใส่เครื่องหมายคําพูด คีย์เวิร์ดและโอเปอเรเตอร์จะถือเป็นคําธรรมดา เช่น some เป็นคีย์เวิร์ด แต่ "บาง" เป็นคํา ทั้ง foo และ "foo" เป็นคำ

    อย่างไรก็ตาม โปรดระมัดระวังเมื่อใช้เครื่องหมายคำพูดเดี่ยวหรือคู่ในชื่อเป้าหมาย เมื่อใส่เครื่องหมายคำพูดในชื่อเป้าหมายอย่างน้อย 1 ชื่อ ให้ใช้เครื่องหมายคำพูดเพียง 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 ที่ไม่ระบุ

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

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

โปรดทราบว่าเนื่องจากคำค้นหาไม่ได้พิจารณาการกำหนดค่า การใช้งาน Toolchain ที่เป็นไปได้จึงไม่ถือว่าเป็นทรัพยากร Dependency เนื่องจากเป็นประเภท Toolchain ที่จำเป็นเท่านั้น ดูเอกสารประกอบเกี่ยวกับเครื่องมือทํางาน

ความเสียง

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

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

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

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

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

deps(x) union y

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

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

การค้นหาท้องฟ้า

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

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

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

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

โหมดการค้นหาท้องฟ้าจะเปิดใช้งานโดยการส่ง Flag 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 เท่านั้น เนื่องด้วยระบบไม่ได้สร้างความสัมพันธ์แบบย้อนกลับของ //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 มีข้อดีและข้อเสียบางอย่างเมื่อเทียบกับการค้นหาเริ่มต้น ข้อเสียหลักคือไม่สามารถจัดลําดับเอาต์พุตตามลําดับกราฟได้ จึงห้ามใช้รูปแบบเอาต์พุตบางอย่าง ข้อดีคือมีโอเปอเรเตอร์ 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 โดยที่ค่าของ expr1 จะแทนที่ตัวแปร name ทั้งหมดที่ปรากฏขึ้น

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

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

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

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

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

ในทางเทคนิคแล้ว นิพจน์ 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 ...) โอเปอเรเตอร์จะคํานวณยูเนียนของชุดรูปแบบเป้าหมายอย่างน้อย 1 ชุด โดยคั่นด้วยเว้นวรรค (ไม่มีคอมมา)

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

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) แต่อาจใช้คำสั่งเชลล์อื่นๆ นอกเหนือจาก cat ได้ด้วย เช่น คำสั่ง awk ก่อนหน้า

ฟังก์ชัน

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

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

ปิดเชิงการเปลี่ยนรูปแบบของ Dependency: deps

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

ตัวดำเนินการ deps(x) จะประเมินเป็นกราฟที่สร้างขึ้นจากความสัมพันธ์แบบทรานซิทีฟของชุดอาร์กิวเมนต์ 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 ยอมรับอาร์กิวเมนต์ที่สาม (ไม่บังคับ) ซึ่งเป็นจำนวนเต็มที่ระบุขอบเขตบนของความลึกของการค้นหา กราฟที่เป็นผลลัพธ์จะรวมเฉพาะโหนดที่อยู่ในระยะของความลึกที่ระบุจากโหนดใดๆ ในชุดอาร์กิวเมนต์ ดังนั้น rdeps(//foo, //common, 1) จึงประเมินเป็นโหนดทั้งหมดใน Closure แบบทรานซิทีฟของ //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 จะคำนวณฟังก์ชันข้อมูลประจำตัว: 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

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

Somepath
somepath(S1 + S2, E) ผลลัพธ์ที่เป็นไปได้ 1 รายการ
Somepath
somepath(S1 + S2, E) ซึ่งเป็นผลลัพธ์ที่เป็นไปได้อีกรายการ
Allpaths
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 กฎ Genrule
//p:a.in ไฟล์ต้นฉบับ
//p:a.out ไฟล์ที่สร้างขึ้น
//p:BUILD ไฟล์ต้นฉบับ

ดังนั้น kind("cc_.* rule", foo/...) จะประเมินเป็นชุดของ cc_library, cc_binary ทั้งหมด ฯลฯ ซึ่งเป็นเป้าหมายของกฎที่อยู่ใต้ foo และ kind("source file", deps(//foo)) จะประเมินเป็นชุดของไฟล์ต้นฉบับทั้งหมดใน Closure แบบโอนย้ายได้ของ 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 เนื่องจากชื่อเป้าหมายทั้งหมดขึ้นต้นด้วย // คุณจึงใช้ // แทนตัวยึดตําแหน่งนิพจน์ทั่วไปได้^

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

อ argum แรก 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))

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

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

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

หากต้องการเลือกกฎทั้งหมดในหมู่//foo Dependency ที่มี 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: tests

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

ไฟล์คําจํากัดความแพ็กเกจ: buildfiles

expr ::= buildfiles(expr)

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

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

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

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

ไฟล์คําจํากัดความของแพ็กเกจ: 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 ไม่ใช่เป้าหมายเหล่านั้น แต่เป็นส่วนย่อยของเส้นทางที่สอดคล้องกับเป้าหมายเหล่านั้น

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

expr ::= loadfiles(expr)

อ operators 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 นอกจากนี้ โหนดที่เทียบเท่ากันในลําดับความขึ้นต่อกันอาจเรียงตามลําดับตัวอักษรหรือไม่ก็ได้ คุณใช้แฟล็ก --order_output เพื่อควบคุมลักษณะการทำงานนี้ได้ (ธง --[no]order_results มีฟังก์ชันการทำงานส่วนหนึ่งของธง --order_output และเลิกใช้งานแล้ว)

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

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

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

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

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

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

--output build

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

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

--output label

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

เมื่อพิมพ์เอาต์พุตของข้อความค้นหา 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 แบบแบ่งความยาว ซึ่งมีประโยชน์ในการ(1) หลีกเลี่ยงข้อจำกัดด้านขนาดของบัฟเฟอร์โปรโตคอลเมื่อมีเป้าหมายมากเกินไปที่จะใส่ในQueryResult รายการเดียว หรือ(2) เพื่อเริ่มการประมวลผลขณะที่ Bazel ยังคงแสดงผลอยู่

--output textproto

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

--output streamed_jsonproto

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

--output minrank --output maxrank

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

รูปแบบนี้มี 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) จะใช้เอาต์พุตการค้นหาเพื่อดูชุดการจับคู่ได้เช่นกัน ซึ่งทำให้สามารถใช้เครื่องมือการค้นหาของ Bazel เป็น "grep สำหรับไฟล์ BUILD" ที่รับรู้กราฟความเกี่ยวข้องได้

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

--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 เป็นความเกี่ยวข้องแบบไปข้างหน้า (ข้อกําหนดเบื้องต้น) และเนื้อหาของแอตทริบิวต์ outs เป็นความเกี่ยวข้องแบบย้อนกลับ (ผู้ใช้)

ระบบจะระงับองค์ประกอบ 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 ได้

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

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