กฎทั่วไป

กฎ

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

ชื่อแทน

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

alias rule creates another name a rule can be referred to as.

การกำหนดชื่อแทนใช้ได้กับเป้าหมาย "ปกติ" เท่านั้น โดยเฉพาะอย่างยิ่ง 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, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, 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"
      }
  )
  

การจับคู่ต่อไปนี้จะตรงกับการสร้างที่ตั้งค่า แฟล็กที่ผู้ใช้กำหนด --//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 ทั้งคู่ให้ผลลัพธ์เป็น ["a", "b"] ตรวจสอบคำจำกัดความของ Flag และทดสอบ เงื่อนไขอย่างละเอียดเพื่อยืนยันความคาดหวังที่แน่นอน

• หากต้องการกำหนดเงื่อนไขที่ไม่ได้สร้างแบบจำลองโดยแฟล็กบิลด์ในตัว ให้ใช้ แฟล็กที่กำหนดโดย 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, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

ใช้ filegroup เพื่อตั้งชื่อที่สะดวกให้กับกลุ่มเป้าหมาย จากนั้นจะอ้างอิงจากกฎอื่นๆ ได้

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

ตัวอย่าง

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

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

หรือใช้ glob เพื่อค้นหาไดเรกทอรี 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, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

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

เพื่อให้การสร้างมีความสอดคล้องกัน ระบบจะอนุญาตให้คําค้นหาเข้าชมได้เฉพาะ การปิดทรานซิทีฟของเป้าหมายที่ระบุในแอตทริบิวต์ 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, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

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

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

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

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

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

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

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

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

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

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

กรณีพิเศษ

การคอมไพล์ 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, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, 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

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

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

test_suite

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

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

ตัวอย่าง

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

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"],
)

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