กฎทั่วไป

กติกา

• 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 vs. -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 ทั้งคู่ให้ผลลัพธ์เป็น ["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"],
)

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