กฎพื้นที่ทำงาน

กฎของพื้นที่ทำงานใช้เพื่อดึง ทรัพยากร Dependency ภายนอก ซึ่งโดยปกติจะเป็น ซอร์สโค้ดที่อยู่นอกที่เก็บหลัก

หมายเหตุ: นอกจากกฎของพื้นที่ทำงานแบบเนทีฟแล้ว Bazel ยังฝังกฎของพื้นที่ทำงาน Starlarkต่างๆ ไว้ด้วย โดยเฉพาะกฎที่ใช้จัดการที่เก็บ Git หรือไฟล์เก็บถาวรที่โฮสต์บนเว็บ

กฎ

bind

ดูแหล่งที่มาของกฎ
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

คำเตือน: ไม่แนะนำให้ใช้ bind() โปรดดู "พิจารณานำ bind ออก" เพื่อดูการอภิปรายอย่างละเอียดเกี่ยวกับปัญหาและทางเลือกอื่นๆ โดยเฉพาะอย่างยิ่ง ให้พิจารณาใช้แอตทริบิวต์ที่เก็บ repo_mapping

ประกาศเตือน: ไม่สามารถใช้select() ในbind() ได้ ดูรายละเอียดในคำถามที่พบบ่อยเกี่ยวกับแอตทริบิวต์ที่กำหนดค่าได้สำหรับ รายละเอียด

ให้เป้าหมายมีชื่อแทนในแพ็กเกจ //external

แพ็กเกจ //external ไม่ใช่แพ็กเกจ "ปกติ" เนื่องจากไม่มีไดเรกทอรี external/ จึงถือได้ว่าเป็น "แพ็กเกจเสมือน" ที่มีเป้าหมายทั้งหมดที่ผูกไว้

ตัวอย่าง

หากต้องการให้เป้าหมายมีชื่อแทน ให้ bind เป้าหมายนั้นในไฟล์ WORKSPACE เช่น สมมติว่ามีเป้าหมาย java_library ชื่อ //third_party/javacc-v2 คุณสามารถตั้งชื่อแทนเป้าหมายนี้ได้โดยเพิ่มโค้ดต่อไปนี้ลงในไฟล์ WORKSPACE

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

ตอนนี้เป้าหมายสามารถขึ้นอยู่กับ //external:javacc-latest แทน //third_party/javacc-v2 ได้แล้ว หากมีการเผยแพร่ javacc-v3 คุณสามารถอัปเดตกฎ bind และไฟล์ BUILD ทั้งหมดที่ขึ้นอยู่กับ //external:javacc-latest จะขึ้นอยู่กับ javacc-v3 โดยไม่ต้องแก้ไข

นอกจากนี้ คุณยังใช้ bind เพื่อทำให้เป้าหมายในที่เก็บภายนอกพร้อมใช้งานในพื้นที่ทำงานได้ด้วย เช่น หากมีที่เก็บระยะไกลชื่อ @my-ssl ที่นำเข้าในไฟล์ WORKSPACE และมีเป้าหมาย cc_library //src:openssl-lib คุณสามารถ สร้างชื่อแทนสำหรับเป้าหมายนี้ได้โดยใช้ bind ดังนี้

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

จากนั้นในไฟล์ BUILD ในพื้นที่ทำงาน คุณจะใช้เป้าหมายที่ผูกไว้ได้ดังนี้

cc_library(
    name = "sign-in",
    srcs = ["sign_in.cc"],
    hdrs = ["sign_in.h"],
    deps = ["//external:openssl"],
)

ภายใน sign_in.cc และ sign_in.h คุณสามารถอ้างอิงไฟล์ส่วนหัวที่ //external:openssl เปิดเผยได้โดยใช้เส้นทางสัมพัทธ์กับรูทของที่เก็บ เช่น หากคำจำกัดความของกฎสำหรับ @my-ssl//src:openssl-lib มีลักษณะดังนี้

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

การรวมของ sign_in.cc อาจมีลักษณะดังนี้

#include "sign_in.h"
#include "src/openssl.h"

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

แอตทริบิวต์
name

ชื่อ; ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

actual

ป้ายกำกับ; ค่าเริ่มต้นคือ None

เป้าหมายที่จะตั้งชื่อแทน

เป้าหมายนี้ต้องมีอยู่ แต่จะเป็นกฎประเภทใดก็ได้ (รวมถึง bind)

หากละเว้นแอตทริบิวต์นี้ กฎที่อ้างอิงเป้าหมายนี้ใน //external จะไม่เห็นขอบทรัพยากร Dependency นี้ โปรดทราบว่าการละเว้นกฎ bind ทั้งหมดนั้นแตกต่างจากการละเว้นแอตทริบิวต์นี้ เนื่องจากระบบจะแสดงข้อผิดพลาดหากทรัพยากร Dependency //external ไม่มีกฎ bind ที่เชื่อมโยง

local_repository

ดูแหล่งที่มาของกฎ
local_repository(name, path, repo_mapping)

อนุญาตให้ผูกเป้าหมายจากไดเรกทอรีภายใน ซึ่งหมายความว่าที่เก็บปัจจุบันสามารถ ใช้เป้าหมายที่กำหนดไว้ในไดเรกทอรีอื่นนี้ได้ ดูรายละเอียดเพิ่มเติมในส่วน bind section

ตัวอย่าง

สมมติว่าที่เก็บปัจจุบันเป็นไคลเอ็นต์แชทที่รูทอยู่ที่ไดเรกทอรี ~/chat-app และต้องการใช้ไลบรารี SSL ที่กำหนดไว้ในที่เก็บอื่น ~/ssl ไลบรารี SSL มีเป้าหมาย //src:openssl-lib

ผู้ใช้สามารถเพิ่มทรัพยากร Dependency ในเป้าหมายนี้ได้โดยเพิ่มบรรทัดต่อไปนี้ลงใน ~/chat-app/WORKSPACE:

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

เป้าหมายจะระบุ @my-ssl//src:openssl-lib เป็นทรัพยากร Dependency เพื่อขึ้นอยู่กับไลบรารีนี้

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

แอตทริบิวต์
name

ชื่อ; ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

path

สตริง; ต้องระบุ

เส้นทางไปยังไดเรกทอรีของที่เก็บภายใน

เส้นทางนี้ต้องเป็นเส้นทางไปยังไดเรกทอรีที่มีไฟล์ WORKSPACE ของที่เก็บ เส้นทางอาจเป็นเส้นทางสัมบูรณ์หรือเส้นทางสัมพัทธ์กับไฟล์ WORKSPACE ของที่เก็บหลัก

repo_mapping

พจนานุกรม: สตริง -> สตริง; ค่าเริ่มต้นคือ {}

พจนานุกรมจากชื่อที่เก็บภายในไปยังชื่อที่เก็บส่วนกลาง ซึ่งช่วยให้ควบคุมการแก้ปัญหาทรัพยากร Dependency ของพื้นที่ทำงานสำหรับทรัพยากร Dependency ของที่เก็บนี้ได้

เช่น รายการ "@foo": "@bar" จะประกาศว่าเมื่อใดก็ตามที่ที่เก็บนี้ขึ้นอยู่กับ "@foo" (เช่น ทรัพยากร Dependency ใน "@foo//some:target") ที่เก็บนี้ควรแก้ปัญหาทรัพยากร Dependency นั้นภายใน "@bar" ที่ประกาศไว้ทั่วโลก ("@bar//some:target")

new_local_repository

ดูแหล่งที่มาของกฎ
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)

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

กฎนี้จะสร้างที่เก็บ Bazel โดยการสร้างไฟล์ WORKSPACE และไดเรกทอรีย่อยที่มีลิงก์สัญลักษณ์ไปยังไฟล์ BUILD และเส้นทางที่ระบุ ไฟล์บิลด์ควรสร้างเป้าหมายสัมพัทธ์กับ path สำหรับไดเรกทอรีที่มีไฟล์ WORKSPACE และไฟล์ BUILD อยู่แล้ว คุณสามารถใช้กฎ local_repository ได้

ตัวอย่าง

สมมติว่าที่เก็บปัจจุบันเป็นโปรแกรมแชทที่รูทอยู่ที่ไดเรกทอรี ~/chat-app และต้องการใช้ไลบรารี SSL ที่กำหนดไว้ในไดเรกทอรีอื่น ~/ssl

ผู้ใช้สามารถเพิ่มทรัพยากร Dependency ได้โดยการสร้างไฟล์ BUILD สำหรับไลบรารี SSL (~/chat-app/BUILD.my-ssl) ที่มีโค้ดต่อไปนี้

java_library(
    name = "openssl",
    srcs = glob(['*.java'])
    visibility = ["//visibility:public"],
)

จากนั้นเพิ่มบรรทัดต่อไปนี้ลงใน ~/chat-app/WORKSPACE

new_local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
    build_file = "BUILD.my-ssl",
)

การดำเนินการนี้จะสร้างที่เก็บ @my-ssl ที่ลิงก์สัญลักษณ์ไปยัง /home/user/ssl เป้าหมายสามารถขึ้นอยู่กับไลบรารีนี้ได้โดยการเพิ่ม @my-ssl//:openssl ลงในทรัพยากร Dependency ของเป้าหมาย

นอกจากนี้ คุณยังใช้ new_local_repository เพื่อรวมไฟล์เดียว ไม่ใช่แค่ไดเรกทอรีได้ด้วย เช่น สมมติว่าคุณมีไฟล์ jar อยู่ที่ /home/username/Downloads/piano.jar คุณสามารถเพิ่มไฟล์นั้นลงในบิลด์ได้โดยเพิ่มโค้ดต่อไปนี้ลงในไฟล์ WORKSPACE

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

และสร้างไฟล์ BUILD.piano ต่อไปนี้

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)
จากนั้นเป้าหมายสามารถขึ้นอยู่กับ @piano//:play-music เพื่อใช้ piano.jar ได้

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

แอตทริบิวต์
name

ชื่อ; ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

build_file

ชื่อ; ค่าเริ่มต้นคือ None

ไฟล์ที่จะใช้เป็นไฟล์ BUILD สำหรับไดเรกทอรีนี้

คุณต้องระบุ build_file หรือ build_file_content

แอตทริบิวต์นี้เป็นป้ายกำกับสัมพัทธ์กับพื้นที่ทำงานหลัก ไฟล์ไม่จำเป็นต้องชื่อ BUILD แต่ตั้งชื่อนี้ก็ได้ (ชื่ออย่าง BUILD.new-repo-name อาจเหมาะสำหรับการ แยกไฟล์นี้ออกจากไฟล์ BUILD จริงของที่เก็บ)

build_file_content

สตริง; ค่าเริ่มต้นคือ ""

เนื้อหาสำหรับไฟล์ BUILD ของที่เก็บนี้

คุณต้องระบุ build_file หรือ build_file_content

path

สตริง; ต้องระบุ

เส้นทางในระบบไฟล์ภายใน

เส้นทางนี้อาจเป็นเส้นทางสัมบูรณ์หรือเส้นทางสัมพัทธ์กับไฟล์ WORKSPACE ของที่เก็บหลัก

repo_mapping

พจนานุกรม: สตริง -> สตริง; ค่าเริ่มต้นคือ {}

พจนานุกรมจากชื่อที่เก็บภายในไปยังชื่อที่เก็บส่วนกลาง ซึ่งช่วยให้ควบคุมการแก้ปัญหาทรัพยากร Dependency ของพื้นที่ทำงานสำหรับทรัพยากร Dependency ของที่เก็บนี้ได้

เช่น รายการ "@foo": "@bar" จะประกาศว่าเมื่อใดก็ตามที่ที่เก็บนี้ขึ้นอยู่กับ "@foo" (เช่น ทรัพยากร Dependency ใน "@foo//some:target") ที่เก็บนี้ควรแก้ปัญหาทรัพยากร Dependency นั้นภายใน "@bar" ที่ประกาศไว้ทั่วโลก ("@bar//some:target")

workspace_file

ชื่อ; ค่าเริ่มต้นคือ None

ไฟล์ที่จะใช้เป็นไฟล์ WORKSPACE สำหรับที่เก็บนี้

คุณระบุ workspace_file หรือ workspace_file_content อย่างใดอย่างหนึ่งได้ แต่จะระบุทั้ง 2 อย่างไม่ได้

แอตทริบิวต์นี้เป็นป้ายกำกับสัมพัทธ์กับพื้นที่ทำงานหลัก ไฟล์ไม่จำเป็นต้องชื่อ WORKSPACE แต่ตั้งชื่อนี้ก็ได้ (ชื่ออย่าง WORKSPACE.new-repo-name อาจเหมาะสำหรับการแยกไฟล์นี้ออกจากไฟล์ WORKSPACE จริงของที่เก็บ)

workspace_file_content

สตริง; ค่าเริ่มต้นคือ ""

เนื้อหาสำหรับไฟล์ WORKSPACE ของที่เก็บนี้

คุณระบุ workspace_file หรือ workspace_file_content อย่างใดอย่างหนึ่งได้ แต่จะระบุทั้ง 2 อย่างไม่ได้