กฎทั่วไป

กฎ

• alias
• config_setting
• filegroup
• genquery
• genrule
• starlark_doc_extract
• test_suite

ชื่อแทน

alias(name, actual, aspect_hints, compatible_with, deprecation, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, visibility)

alias กฎจะสร้างชื่ออื่นที่ใช้เรียกกฎได้

การตั้งค่าชื่อแทนใช้ได้กับเป้าหมาย "ปกติ" เท่านั้น โดยเฉพาะอย่างยิ่ง package_group และ test_suite จะตั้งชื่อแทนไม่ได้

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

กฎนามแฝงมีการประกาศการมองเห็นของตัวเอง ในด้านอื่นๆ ทั้งหมด จะทำงาน เหมือนกับกฎที่อ้างอิง (เช่น ระบบจะไม่สนใจ testonly ในนามแฝง แต่จะใช้ testonly-ness ของกฎที่อ้างอิงแทน) โดยมีข้อยกเว้นเล็กน้อยดังนี้

• ระบบจะไม่เรียกใช้การทดสอบหากมีการกล่าวถึงนามแฝงในบรรทัดคำสั่ง หากต้องการกำหนดนามแฝง ที่เรียกใช้การทดสอบที่อ้างอิง ให้ใช้กฎ test_suite ที่มีเป้าหมายเดียวในแอตทริบิวต์ tests
• เมื่อกำหนดกลุ่มสภาพแวดล้อม ระบบจะไม่รองรับชื่อแทนของenvironmentกฎ และไม่รองรับในตัวเลือกบรรทัดคำสั่ง --target_environment ด้วย

ตัวอย่าง

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

อาร์กิวเมนต์

config_setting

config_setting(name, aspect_hints, constraint_values, define_values, deprecation, features, flag_values, licenses, package_metadata, tags, testonly, values, visibility)

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

ตัวอย่าง

การจับคู่ต่อไปนี้จะใช้ได้กับบิลด์ที่ตั้งค่า --compilation_mode=opt หรือ -c opt (ไม่ว่าจะตั้งค่าอย่างชัดเจนในบรรทัดคำสั่งหรือโดยนัยจากไฟล์ .bazelrc)

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

รายการต่อไปนี้จะตรงกับบิลด์ที่กำหนดเป้าหมายเป็น ARM และใช้การกำหนดที่กำหนดเอง FOO=bar (เช่น bazel build --cpu=arm --define FOO=bar ...)

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

รายการต่อไปนี้จะตรงกับบิลด์ที่ตั้งค่า Flag ที่ผู้ใช้กำหนด --//custom_flags:foo=1 (ไม่ว่าจะระบุอย่างชัดเจนในบรรทัดคำสั่งหรือโดยนัยจาก ไฟล์ .bazelrc):

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

การจับคู่ต่อไปนี้จะจับคู่บิลด์ที่กำหนดเป้าหมายเป็นแพลตฟอร์มที่มีสถาปัตยกรรม x86_64 และ glibc เวอร์ชัน 2.25 โดยสมมติว่ามี constraint_value ที่มีป้ายกำกับ //example:glibc_2_25 โปรดทราบว่าแพลตฟอร์มจะยังคงตรงกันหากกำหนดค่าข้อจำกัดเพิ่มเติม นอกเหนือจาก 2 ค่านี้

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

หมายเหตุ

• ดูเลือกเพื่อดูสิ่งที่เกิดขึ้นเมื่อมี config_settingหลายรายการที่ตรงกับสถานะการกำหนดค่าปัจจุบัน
• สำหรับ Flag ที่รองรับรูปแบบย่อ (เช่น --compilation_mode กับ -c) values คำจำกัดความต้องใช้รูปแบบเต็ม ระบบจะจับคู่การเรียกใช้โดยอัตโนมัติ โดยใช้รูปแบบใดรูปแบบหนึ่ง
• หากแฟล็กมีหลายค่า (เช่น --copt=-Da --copt=-Db หรือ แฟล็ก Starlark ประเภทรายการ) values = { "flag": "a" } จะตรงกันหาก "a" อยู่ที่ใดก็ได้ในรายการจริง

  values = { "myflag": "a,b" } ทำงานในลักษณะเดียวกัน โดยจะจับคู่กับ --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b และ --myflag=c,b,a ความหมายที่แน่นอนจะแตกต่างกันไปในแต่ละ แฟล็ก เช่น --copt ไม่รองรับหลายค่าในอินสแตนซ์เดียวกัน: --copt=a,b จะสร้าง ["a,b"] ในขณะที่ --copt=a --copt=b จะสร้าง ["a", "b"] (ดังนั้น values = { "copt": "a,b" } จึงตรงกับค่าแรกแต่ไม่ตรงกับค่าที่สอง) แต่ --ios_multi_cpus (สำหรับกฎของ Apple) ทำ: -ios_multi_cpus=a,b และ ios_multi_cpus=a --ios_multi_cpus=b ทั้ง 2 รายการจะสร้าง ["a", "b"] ตรวจสอบคำจำกัดความของฟีเจอร์และทดสอบ เงื่อนไขอย่างละเอียดเพื่อยืนยันความคาดหวังที่แน่นอน

• หากต้องการกำหนดเงื่อนไขที่ไม่ได้สร้างแบบจำลองโดยแฟล็กบิลด์ในตัว ให้ใช้ แฟล็กที่กำหนดโดย Starlark คุณใช้ --define ได้เช่นกัน แต่การรองรับจะน้อยกว่าและเราไม่แนะนำให้ใช้วิธีนี้ ดูการสนทนาเพิ่มเติมได้ที่นี่
• หลีกเลี่ยงการทำซ้ำconfig_settingคำจำกัดความที่เหมือนกันในแพ็กเกจต่างๆ แต่ให้อ้างอิง config_setting ทั่วไปที่กำหนดไว้ในแพ็กเกจ Canonical แทน
• values define_values และ constraint_values สามารถใช้ร่วมกันได้ในconfig_setting เดียวกัน แต่อย่างน้อยต้องตั้งค่า 1 รายการ สำหรับconfig_setting ที่กำหนด

อาร์กิวเมนต์

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

กลุ่มไฟล์

filegroup(name, srcs, data, aspect_hints, compatible_with, deprecation, features, licenses, output_group, package_metadata, restricted_to, tags, target_compatible_with, testonly, visibility)

ใช้ filegroup เพื่อรวบรวมเอาต์พุตของชุดเป้าหมายภายใต้ป้ายกำกับเดียว

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

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

ตัวอย่าง

หากต้องการสร้าง filegroup ที่ประกอบด้วยไฟล์ต้นฉบับ 2 ไฟล์ ให้ทำดังนี้

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "//a/library:target",
        "//a/binary:target",
    ],
)

หรือใช้ glob เพื่อทำการ Crawl ไดเรกทอรี testdata อย่างเต็มรูปแบบ

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

หากต้องการใช้คำจำกัดความเหล่านี้ ให้อ้างอิง filegroup พร้อมป้ายกำกับจากกฎใดก็ได้

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

อาร์กิวเมนต์

genquery

genquery(name, deps, data, aspect_hints, compatible_with, compressed_output, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, expression, features, licenses, opts, package_metadata, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery() เรียกใช้การค้นหาที่ระบุไว้ใน ภาษาการค้นหาของ Bazel และส่งผลลัพธ์ ไปยังไฟล์

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

ความแตกต่างเพียงอย่างเดียวระหว่างคำค้นหาที่อนุญาตที่นี่กับในบรรทัดคำสั่งคือไม่อนุญาตให้ใช้คำค้นหาที่มีข้อกำหนดเป้าหมายแบบไวลด์การ์ด (เช่น //pkg:* หรือ //pkg:all) ที่นี่ เหตุผลมี 2 ประการ ประการแรกคือ genquery ต้องระบุขอบเขตเพื่อป้องกันไม่ให้เป้าหมายภายนอกการปิดทรานซิทีฟของคำค้นหามีผลต่อเอาต์พุต และประการที่สองคือไฟล์ BUILD ไม่รองรับการขึ้นต่อกันแบบไวลด์การ์ด (เช่น deps=["//a/..."] ไม่ได้รับอนุญาต)

เอาต์พุตของ genquery จะเรียงตามลำดับพจนานุกรมเพื่อบังคับใช้เอาต์พุตที่แน่นอน ยกเว้น --output=graph|minrank|maxrank หรือเมื่อใช้ somepath เป็นฟังก์ชันระดับบนสุด

ชื่อไฟล์เอาต์พุตคือชื่อของกฎ

ตัวอย่าง

ตัวอย่างนี้จะเขียนรายการป้ายกำกับใน Closure แบบทรานซิทีฟของเป้าหมายที่ระบุลงในไฟล์

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

อาร์กิวเมนต์

genrule

genrule(name, srcs, outs, aspect_hints, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genruleสร้างไฟล์อย่างน้อย 1 ไฟล์โดยใช้คำสั่ง Bash ที่ผู้ใช้กำหนด

Genrules เป็นกฎการสร้างทั่วไปที่คุณใช้ได้หากไม่มีกฎเฉพาะสำหรับงาน เช่น คุณสามารถเรียกใช้คำสั่ง Bash แบบบรรทัดเดียวได้ อย่างไรก็ตาม หากคุณต้องการคอมไพล์ไฟล์ C++ ให้ใช้cc_*กฎที่มีอยู่ต่อไป เนื่องจากเราได้ดำเนินการที่ซับซ้อนทั้งหมดให้คุณแล้ว

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

เช่นเดียวกับการดำเนินการอื่นๆ การดำเนินการที่สร้างโดย genrules ไม่ควรสมมติสิ่งใดเกี่ยวกับ ไดเรกทอรีการทำงาน สิ่งที่ Bazel รับประกันทั้งหมดคืออินพุตที่ประกาศไว้จะพร้อมใช้งานที่ เส้นทางที่ $(location) แสดงผลสำหรับป้ายกำกับ ตัวอย่างเช่น หากมีการเรียกใช้การดำเนินการใน แซนด์บ็อกซ์หรือจากระยะไกล การติดตั้งใช้งานแซนด์บ็อกซ์หรือการดำเนินการจากระยะไกลจะเป็นตัวกำหนด ไดเรกทอรีการทำงาน หากเรียกใช้โดยตรง (ใช้กลยุทธ์ standalone) ไดเรกทอรีการทำงานจะเป็นรูทการดำเนินการ นั่นคือ ผลลัพธ์ของ bazel info execution_root

อย่าใช้ genrule สำหรับการเรียกใช้การทดสอบ มีการยกเว้นพิเศษสำหรับการทดสอบและผลการทดสอบ รวมถึงนโยบายการแคชและตัวแปรสภาพแวดล้อม โดยทั่วไปแล้ว การทดสอบจะต้องดำเนินการ หลังจากสร้างเสร็จและในสถาปัตยกรรมเป้าหมาย ในขณะที่ genrule จะดำเนินการระหว่าง การสร้างและในสถาปัตยกรรม exec (ทั้ง 2 อย่างอาจแตกต่างกัน) หากต้องการกฎการทดสอบทั่วไป ให้ใช้ sh_test

ข้อควรพิจารณาในการคอมไพล์แบบข้ามระบบ

ดูข้อมูลเพิ่มเติมเกี่ยวกับการคอมไพล์ข้ามได้ในคู่มือผู้ใช้

แม้ว่า genrules จะทำงานระหว่างการสร้าง แต่เอาต์พุตมักจะใช้หลังจากการสร้างสำหรับการติดตั้งใช้งานหรือ การทดสอบ ลองพิจารณาตัวอย่างการคอมไพล์โค้ด C สำหรับไมโครคอนโทรลเลอร์ โดยคอมไพเลอร์จะยอมรับไฟล์ต้นฉบับ C และสร้างโค้ดที่ทำงานในไมโครคอนโทรลเลอร์ โค้ดที่สร้างขึ้นจะรันบน CPU ที่ใช้สร้างไม่ได้อย่างแน่นอน แต่คอมไพเลอร์ C (หากคอมไพล์จากแหล่งที่มา) ต้องรันได้

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

สำหรับ genrules ระบบบิลด์จะตรวจสอบว่ามีการสร้างการขึ้นต่อกันอย่างเหมาะสม ดังนี้ มีการสร้าง srcs (หากจำเป็น) สำหรับการกำหนดค่า target มีการสร้าง tools สำหรับการกำหนดค่า exec และระบบจะถือว่าเอาต์พุต เป็นการกำหนดค่า target นอกจากนี้ ยังมี ตัวแปร "Make" ที่คำสั่ง genrule สามารถส่งไปยังเครื่องมือที่เกี่ยวข้องได้

เราตั้งใจที่จะไม่กำหนดแอตทริบิวต์ deps ใน genrule เนื่องจากกฎในตัวอื่นๆ ใช้ข้อมูลเมตาที่ขึ้นอยู่กับภาษาซึ่งส่งผ่านระหว่างกฎเพื่อกำหนดวิธีจัดการกฎที่ขึ้นต่อกันโดยอัตโนมัติ แต่การทำงานอัตโนมัติในระดับนี้ไม่สามารถใช้กับ genrule ได้ Genrules ทำงาน ที่ระดับไฟล์และไฟล์ที่เรียกใช้เท่านั้น

กรณีพิเศษ

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

เครื่องมือ JDK และ C++: หากต้องการใช้เครื่องมือจาก JDK หรือชุดคอมไพเลอร์ C++ ระบบบิลด์ จะมีชุดตัวแปรให้ใช้ ดูรายละเอียดได้ที่ตัวแปร "Make"

สภาพแวดล้อม Genrule

คำสั่ง genrule จะดำเนินการโดยเชลล์ Bash ที่กำหนดค่าให้ล้มเหลวเมื่อคำสั่ง หรือไปป์ไลน์ล้มเหลว โดยใช้ set -e -o pipefail

เครื่องมือบิลด์จะเรียกใช้คำสั่ง Bash ในสภาพแวดล้อมของกระบวนการที่ผ่านการล้างข้อมูล ซึ่ง กำหนดเฉพาะตัวแปรหลัก เช่น PATH, PWD, TMPDIR และตัวแปรอื่นๆ อีก 2-3 ตัว เพื่อให้มั่นใจว่าบิลด์สามารถทำซ้ำได้ ระบบจะไม่ส่งตัวแปรส่วนใหญ่ที่กำหนดไว้ในเชลล์ของผู้ใช้ ไปยังคำสั่งของ genrule อย่างไรก็ตาม Bazel (แต่ไม่ใช่ Blaze) จะส่งค่าของตัวแปรสภาพแวดล้อม PATH ของผู้ใช้ การเปลี่ยนแปลงค่าของ PATH จะทำให้ Bazel เรียกใช้คำสั่งอีกครั้ง ในการสร้างครั้งถัดไป

คำสั่ง genrule ไม่ควรเข้าถึงเครือข่าย ยกเว้นเพื่อเชื่อมต่อกระบวนการที่เป็น กระบวนการย่อยของคำสั่งนั้นเอง แม้ว่าปัจจุบันจะไม่มีการบังคับใช้ก็ตาม

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

คำแนะนำทั่วไป

• โปรดตรวจสอบว่าเครื่องมือที่ genrule เรียกใช้เป็นแบบดีเทอร์มินิสติกและเฮอร์เมติก โดยไม่ควรเขียน การประทับเวลาลงในเอาต์พุต และควรใช้การจัดลำดับที่เสถียรสำหรับชุดและแผนที่ รวมถึง เขียนเฉพาะเส้นทางไฟล์แบบสัมพัทธ์ไปยังเอาต์พุตเท่านั้น ไม่ใช่เส้นทางแบบสัมบูรณ์ การไม่ปฏิบัติตามกฎนี้จะ ทําให้เกิดลักษณะการทํางานของบิลด์ที่ไม่คาดคิด (Bazel ไม่สร้าง genrule ที่คุณคิดว่าจะสร้าง) และ ทําให้ประสิทธิภาพของแคชลดลง
• ใช้ $(location) อย่างกว้างขวางสำหรับเอาต์พุต เครื่องมือ และแหล่งที่มา เนื่องจากมีการแยกไฟล์เอาต์พุตสำหรับการกำหนดค่าต่างๆ genrule จึงไม่สามารถใช้เส้นทางที่ฮาร์ดโค้ด และ/หรือเส้นทางแบบสัมบูรณ์ได้
• เขียนมาโคร Starlark ทั่วไปในกรณีที่มีการใช้ genrule เดียวกันหรือคล้ายกันมากในหลายที่ หาก genrule มีความซับซ้อน ให้พิจารณาใช้ในสคริปต์หรือเป็น กฎ Starlark ซึ่งจะช่วยให้อ่านและทดสอบได้ง่ายขึ้น
• โปรดตรวจสอบว่ารหัสออกระบุความสำเร็จหรือความล้มเหลวของ genrule อย่างถูกต้อง
• อย่าเขียนข้อความข้อมูลไปยัง stdout หรือ stderr แม้ว่าจะมีประโยชน์สำหรับการแก้ไขข้อบกพร่อง แต่ก็อาจ กลายเป็นเสียงรบกวนได้ง่ายๆ genrule ที่สำเร็จควรไม่มีเอาต์พุต ในทางกลับกัน genrule ที่ล้มเหลว ควรแสดงข้อความแสดงข้อผิดพลาดที่ดี
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x)
• หลีกเลี่ยงการสร้างลิงก์สัญลักษณ์และไดเรกทอรี Bazel จะไม่คัดลอกโครงสร้างไดเรกทอรี/ซิมลิงก์ ที่สร้างโดย genrule และการตรวจสอบการขึ้นต่อกันของไดเรกทอรีก็ไม่ถูกต้อง
• เมื่ออ้างอิง genrule ในกฎอื่นๆ คุณจะใช้ป้ายกำกับของ genrule หรือป้ายกำกับของไฟล์เอาต์พุตแต่ละไฟล์ก็ได้ บางครั้งวิธีหนึ่งอาจอ่านง่ายกว่า แต่อีกวิธีหนึ่งอาจอ่านง่ายกว่าในบางครั้ง การอ้างอิงเอาต์พุตตามชื่อใน srcs ของกฎที่ใช้จะช่วยหลีกเลี่ยง การเลือกเอาต์พุตอื่นๆ ของ genrule โดยไม่ตั้งใจ แต่ก็อาจน่าเบื่อหาก genrule สร้างเอาต์พุตจำนวนมาก

ตัวอย่าง

ตัวอย่างนี้สร้าง foo.h ไม่มีแหล่งที่มาเนื่องจากคำสั่งไม่ได้ใช้ อินพุตใดๆ "ไบนารี" ที่คำสั่งเรียกใช้คือสคริปต์ Perl ในแพ็กเกจเดียวกันกับ genrule

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

ตัวอย่างต่อไปนี้แสดงวิธีใช้ filegroup และเอาต์พุตของ genrule อื่น โปรดทราบว่าการใช้ $(SRCS) แทน คำสั่ง $(location) ที่ชัดเจนก็ใช้ได้เช่นกัน ตัวอย่างนี้ใช้คำสั่งหลังเพื่อ วัตถุประสงค์ในการสาธิต

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

อาร์กิวเมนต์

starlark_doc_extract

starlark_doc_extract(name, deps, src, data, allow_unused_doc_comments, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, package_metadata, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract() จะดึงข้อมูลเอกสารสำหรับกฎ ฟังก์ชัน (รวมถึงมาโคร) ลักษณะ และผู้ให้บริการที่กำหนดหรือส่งออกซ้ำในไฟล์ .bzl หรือ .scl ที่ระบุ เอาต์พุตของกฎนี้คือ ModuleInfo ไบนารีโปรโตตามที่กำหนด ใน stardoc_output.proto ในโครงสร้างแหล่งที่มาของ Bazel

เป้าหมายเอาต์พุตโดยนัย

• name.binaryproto (เอาต์พุตเริ่มต้น): A ModuleInfo ไบนารีโปรโต
• name.textproto (สร้างขึ้นเมื่อมีการขออย่างชัดเจนเท่านั้น): ข้อความ โปรโตเวอร์ชันของ name.binaryproto

อาร์กิวเมนต์

test_suite

test_suite(name, aspect_hints, compatible_with, deprecation, features, licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite จะกำหนดชุดการทดสอบที่ถือว่า "มีประโยชน์" ต่อมนุษย์ ซึ่งจะช่วยให้โปรเจ็กต์กำหนดชุดการทดสอบได้ เช่น "การทดสอบที่คุณต้องเรียกใช้ก่อนเช็คอิน" "การทดสอบความเครียดของโปรเจ็กต์" หรือ "การทดสอบขนาดเล็กทั้งหมด" คำสั่ง bazel test จะพิจารณาการจัดระเบียบประเภทนี้ สำหรับการเรียกใช้ เช่น bazel test //some/test:suite Bazel จะแจงนับเป้าหมายการทดสอบทั้งหมดที่รวมอยู่โดยอ้อมในเป้าหมาย //some/test:suite ก่อน (เราเรียกขั้นตอนนี้ว่า "การขยาย test_suite") จากนั้น Bazel จะสร้างและทดสอบเป้าหมายเหล่านั้น

ตัวอย่าง

ชุดทดสอบเพื่อเรียกใช้การทดสอบขนาดเล็กทั้งหมดในแพ็กเกจปัจจุบัน

test_suite(
    name = "small_tests",
    tags = ["small"],
)

ชุดทดสอบที่เรียกใช้ชุดการทดสอบที่ระบุ

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

ชุดทดสอบเพื่อเรียกใช้การทดสอบทั้งหมดในแพ็กเกจปัจจุบันซึ่งไม่ไม่เสถียร

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

อาร์กิวเมนต์