สร้างตัวแปร

mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion'
$(SRC)
genrule_srcs_expansion
)
แล้วใช้ "$$\{SRCS[@]}" ในบรรทัดคำสั่งที่ตามมาแทน $(SRCS) ตัวเลือกที่เสถียรกว่าคือการเขียนกฎ Starlark แทน



ตัวแปรเส้นทางแหล่งที่มา/เอาต์พุตที่กำหนดไว้ล่วงหน้า

  ตัวแปรที่กำหนดไว้ล่วงหน้า execpath, execpaths,
  rootpath, rootpaths, location, และ
  locations ใช้พารามิเตอร์ป้ายกำกับ (เช่น $(execpath
  //foo:bar)) และแทนที่เส้นทางไฟล์ที่ระบุโดยป้ายกำกับนั้น



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



  ดูตัวอย่างตัวแปรเส้นทางที่กำหนดไว้ล่วงหน้า


  

    

      execpath:  ระบุเส้นทางใต้

      execroot
    ที่ Bazel เรียกใช้การดำเนินการบิลด์
    
    

      ในตัวอย่างข้างต้น Bazel จะเรียกใช้การดำเนินการบิลด์ทั้งหมดในไดเรกทอรีที่ลิงก์
      โดย Symlink bazel-myproject ในรูทของพื้นที่ทำงาน ไฟล์ต้นฉบับ empty.source จะลิงก์อยู่ที่เส้นทาง
      bazel-myproject/testapp/empty.source ดังนั้นเส้นทาง exec (ซึ่ง
คือเส้นทางย่อยใต้รูท) คือ testapp/empty.source นี่คือเส้นทางที่การดำเนินการบิลด์ใช้เพื่อค้นหาไฟล์

    
    

      ไฟล์เอาต์พุตจะมีการจัดเตรียมในลักษณะเดียวกัน แต่จะมีคำนำหน้าเป็นเส้นทางย่อย
      bazel-out/cpu-compilation_mode/bin (หรือสำหรับเอาต์พุตของ
      เครื่องมือ: bazel-out/cpu-opt-exec-hash/bin) ในตัวอย่างข้างต้น
      //testapp:app เป็นเครื่องมือเนื่องจากปรากฏใน
      show_app_output's tools แอตทริบิวต์
      ดังนั้นไฟล์เอาต์พุต app จะเขียนลงใน
      bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app
      เส้นทาง exec จึงเป็น 
      bazel-out/cpu-opt-exec-hash/bin/testapp/app คำนำหน้าเพิ่มเติมนี้
ช่วยให้สามารถสร้างเป้าหมายเดียวกันสำหรับ เช่น CPU 2 รายการที่แตกต่างกันในการบิลด์เดียวกันได้โดยไม่ให้ผลลัพธ์ทับกัน
    
    

      ป้ายกำกับที่ส่งผ่านไปยังตัวแปรนี้ต้องแสดงถึงไฟล์ 1 ไฟล์เท่านั้น สำหรับ
ป้ายกำกับที่แสดงถึงไฟล์ต้นฉบับ เงื่อนไขนี้จะเป็นจริงโดยอัตโนมัติ สำหรับป้ายกำกับ
ที่แสดงถึงกฎ กฎต้องสร้างเอาต์พุต 1 รายการเท่านั้น หากเงื่อนไขนี้เป็น
เท็จหรือป้ายกำกับมีรูปแบบไม่ถูกต้อง บิลด์จะล้มเหลวพร้อมข้อผิดพลาด
    
  

  

    

      rootpath: ระบุเส้นทางที่ไบนารีที่สร้างขึ้นใช้เพื่อ
ค้นหาทรัพยากร Dependency ในรันไทม์ที่สัมพันธ์กับไดเรกทอรีย่อยของไดเรกทอรี Runfiles ที่สอดคล้องกับที่เก็บหลัก
      หมายเหตุ: ตัวแปรนี้จะทำงานได้ก็ต่อเมื่อเปิดใช้ 
      --enable_runfiles ซึ่งไม่ได้เปิดใช้ใน
      Windows โดยค่าเริ่มต้น โปรดใช้ rlocationpath แทนเพื่อรองรับหลายแพลตฟอร์ม
    

      ตัวแปรนี้คล้ายกับ execpath แต่จะนำคำนำหน้าการกำหนดค่า
ที่อธิบายไว้ข้างต้นออก ในตัวอย่างจากด้านบน หมายความว่าทั้ง
      empty.source และ app ใช้เส้นทางที่สัมพันธ์กับพื้นที่ทำงานล้วนๆ
      ได้แก่ testapp/empty.source และ testapp/app
    
    

      rootpath ของไฟล์ในที่เก็บภายนอก
      repo จะขึ้นต้นด้วย ../repo/ ตามด้วย
      เส้นทางที่สัมพันธ์กับที่เก็บ
    
    

      ตัวแปรนี้มีข้อกำหนด "เอาต์พุต 1 รายการเท่านั้น" เหมือนกับ execpath
    
  

  

    

      rlocationpath: เส้นทางที่ไบนารีที่สร้างขึ้นส่งผ่านไปยังฟังก์ชัน 
      Rlocation ของไลบรารี Runfiles เพื่อค้นหาทรัพยากร Dependency ในรันไทม์ ไม่ว่าจะอยู่ในไดเรกทอรี Runfiles (หากมี) หรือใช้ไฟล์ Manifest ของ Runfiles
    
    

      ตัวแปรนี้คล้ายกับ rootpath ตรงที่จะไม่มี
คำนำหน้าการกำหนดค่า แต่จะแตกต่างกันตรงที่จะขึ้นต้นด้วย
ชื่อที่เก็บเสมอ ในตัวอย่างจากด้านบน หมายความว่า 
      empty.source และ app จะได้เส้นทางต่อไปนี้: myproject/testapp/empty.source และ 
      myproject/testapp/app
    
    

      The rlocationpath ของไฟล์ในที่เก็บภายนอก
      repo จะขึ้นต้นด้วย repo/ ตามด้วย
      เส้นทางที่สัมพันธ์กับที่เก็บ
    
    

      การส่งเส้นทางนี้ไปยังไบนารีและการแปลงเส้นทางนี้เป็นเส้นทางระบบไฟล์โดยใช้
ไลบรารี Runfiles เป็นแนวทางที่แนะนำในการค้นหาการขึ้นต่อกันใน
รันไทม์ ตัวแปรนี้มีข้อดีกว่า rootpath ตรงที่จะทำงานได้ในทุกแพลตฟอร์มและแม้ว่าจะไม่มีไดเรกทอรี Runfiles ก็ตาม
    
    

      ตัวแปรนี้มีข้อกำหนด "เอาต์พุต 1 รายการเท่านั้น" เหมือนกับ execpath
    
  

  

    location: คำพ้องความหมายของ execpath หรือ
 rootpath ขึ้นอยู่กับแอตทริบิวต์ที่ขยาย นี่คือ
ลักษณะการทำงานเดิมก่อน Starlark และไม่แนะนำให้ใช้เว้นแต่คุณจะทราบอย่างแน่ชัดว่า
ตัวแปรนี้ทำอะไรสำหรับกฎหนึ่งๆ ดูรายละเอียดได้ที่ #2475

  



  execpaths, rootpaths, rlocationpaths,
 และ locations เป็นรูปแบบพหูพจน์ของ execpath,
 rootpath, rlocationpath, และlocation,
 ตามลำดับ ตัวแปรเหล่านี้รองรับป้ายกำกับที่สร้างเอาต์พุตหลายรายการ ในกรณีนี้
 ระบบจะแสดงเอาต์พุตแต่ละรายการโดยคั่นด้วยช่องว่าง กฎที่ไม่มีเอาต์พุตและป้ายกำกับที่มีรูปแบบไม่ถูกต้อง
 จะทำให้เกิดข้อผิดพลาดในการบิลด์



  ป้ายกำกับทั้งหมดที่อ้างอิงต้องปรากฏใน srcs,
 ไฟล์เอาต์พุต หรือ deps ของเป้าหมายที่ใช้ มิเช่นนั้นบิลด์จะล้มเหลว เป้าหมาย C++ ยังอ้างอิงป้ายกำกับใน data ได้ด้วย




  ป้ายกำกับไม่จำเป็นต้องอยู่ในรูปแบบ Canonical โดย foo, :foo
 และ //somepkg:foo ใช้ได้ทั้งหมด


ตัวแปรที่กำหนดเอง


  ตัวแปร "Make" ที่กำหนดเองสามารถอ้างอิงได้โดยแอตทริบิวต์ใดก็ตามที่ทำเครื่องหมายเป็น
  "Subject to 'Make variable' substitution", แต่เฉพาะในเป้าหมายที่
  ขึ้นต่อกันกับเป้าหมายอื่นๆ ที่ กำหนด ตัวแปรเหล่านี้



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


ตัวแปรทูลเชน C++

  ตัวแปรต่อไปนี้กำหนดไว้ในกฎทูลเชน C++ และใช้ได้กับกฎใดก็ตาม
 ที่ตั้งค่า toolchains =
  ["@bazel_tools//tools/cpp:toolchain_type"]
 กฎบางอย่าง เช่น java_binary จะรวมทูลเชน C++ ไว้ในคำจำกัดความของกฎโดยนัย ตัวแปรเหล่านี้จะสืบทอดโดยอัตโนมัติ




  กฎ C++ ในตัวมีความซับซ้อนมากกว่า "เรียกใช้คอมไพเลอร์ใน
  กฎ" มาก เพื่อให้รองรับโหมดการคอมไพล์ที่หลากหลาย เช่น *SAN, ThinLTO,
 with/without modules และไบนารีที่ได้รับการปรับให้เหมาะสมอย่างระมัดระวังไปพร้อมๆ กับ
 การทดสอบที่ทำงานได้อย่างรวดเร็วในหลายแพลตฟอร์ม กฎในตัวจึงพยายามอย่างเต็มที่เพื่อให้แน่ใจว่ามีการตั้งค่า
 อินพุต เอาต์พุต และแฟล็กบรรทัดคำสั่งที่ถูกต้องในการดำเนินการที่อาจสร้างขึ้นภายในหลายรายการ




  ตัวแปรเหล่านี้เป็นกลไกการทำงานแบบย้อนกลับที่ผู้เชี่ยวชาญด้านภาษาใช้ใน
 กรณีที่พบได้ยาก หากคุณต้องการใช้ตัวแปรเหล่านี้ โปรด ติดต่อทีมพัฒนา Bazel ก่อน



  
ABI: เวอร์ชัน ABI ของ C++ 

  
 AR: คำสั่ง "ar" จาก Crosstool 
  
 C_COMPILER:
 ตัวระบุคอมไพเลอร์ C/C++ เช่น llvm
  
  

    
CC: คำสั่งคอมไพเลอร์ C และ C++
    

      เราขอแนะนำอย่างยิ่งให้ใช้ CC_FLAGS ร่วมกับ CC เสมอ หากไม่ทำเช่นนั้น คุณจะต้องรับความเสี่ยงเอง
    
  
  
CC_FLAGS: ชุดแฟล็กขั้นต่ำสำหรับคอมไพเลอร์ C/C++
 ที่ genrule ใช้ได้ โดยเฉพาะอย่างยิ่ง แฟล็กนี้มีแฟล็กสำหรับ
เลือกสถาปัตยกรรมที่ถูกต้องหาก CC รองรับหลาย
สถาปัตยกรรม
  


  
 DUMPBIN: Microsoft COFF Binary File Dumper (dumpbin.exe) จาก
 จาก Microsoft Visual Studio 

  
 NM: คำสั่ง "nm" จาก Crosstool 
  
 OBJCOPY: คำสั่ง objcopy จากชุดเครื่องมือเดียวกันกับคอมไพเลอร์ C/C++
 

  
 STRIP: คำสั่ง strip จากชุดเครื่องมือเดียวกันกับคอมไพเลอร์ C/C++



ตัวแปร Toolchain Java


  ตัวแปรต่อไปนี้กำหนดไว้ในกฎ Toolchain Java และใช้ได้กับกฎใดก็ตาม
 ที่ตั้งค่า toolchains =
["@rules_java//toolchains:current_java_runtime"] (หรือ
 "@rules_java//toolchains:current_host_java_runtime"
 สำหรับ Toolchain โฮสต์ที่เทียบเท่า)



  ไม่ควรใช้เครื่องมือส่วนใหญ่ใน JDK โดยตรง กฎ Java ในตัวใช้วิธีการที่ซับซ้อนกว่ามากในการคอมไพล์และสร้างแพ็กเกจ Java ซึ่งเครื่องมือต้นน้ำไม่สามารถแสดงได้ เช่น อินเทอร์เฟซ Jar, อินเทอร์เฟซส่วนหัว Jar รวมถึงการใช้งานการสร้างแพ็กเกจและการผสาน Jar ที่ได้รับการปรับให้เหมาะสมอย่างมาก



  ตัวแปรเหล่านี้เป็นกลไกการทำงานแบบย้อนกลับที่ผู้เชี่ยวชาญด้านภาษาใช้ใน
 กรณีที่พบได้ยาก หากคุณต้องการใช้ตัวแปรเหล่านี้ โปรด ติดต่อทีมพัฒนา Bazel ก่อน



  
 JAVA: คำสั่ง "java" (Java Virtual
 machine) หลีกเลี่ยงการใช้คำสั่งนี้และใช้กฎ java_binary แทนหากเป็นไปได้
 อาจเป็นเส้นทางที่สัมพันธ์ หากคุณต้องเปลี่ยน
ไดเรกทอรี ก่อนที่จะเรียกใช้ java คุณจะต้องบันทึก
ไดเรกทอรีการทำงานก่อนที่จะเปลี่ยน
  

  
JAVABASE: ไดเรกทอรีฐานที่มียูทิลิตี Java อาจเป็นเส้นทางที่สัมพันธ์ โดยจะมีไดเรกทอรีย่อย "bin"
 subdirectory.
  


ตัวแปรที่กำหนดโดย Starlark


  ผู้เขียนกฎและToolchainสามารถกำหนดตัวแปรที่กำหนดเองได้อย่างสมบูรณ์โดยการแสดงผลTemplateVariableInfo กฎใดก็ตามที่ขึ้นต่อกันกับตัวแปรเหล่านี้ผ่านแอตทริบิวต์
  toolchains จะอ่านค่าของตัวแปรได้ดังนี้



  ดูตัวอย่างตัวแปรที่กำหนดโดย Starlark