กฎพื้นที่ทำงานใช้เพื่อดึงทรัพยากร Dependency ภายนอก ซึ่งโดยทั่วไปแล้ว ซอร์สโค้ดที่อยู่นอกที่เก็บหลัก
หมายเหตุ: นอกจากกฎพื้นที่ทำงานของระบบแล้ว Bazel ยังฝังพารามิเตอร์ กฎพื้นที่ทำงาน Starlark โดยเฉพาะกฎที่ต้องจัดการ ที่มีที่เก็บ Git หรือที่เก็บถาวรที่โฮสต์บนเว็บ
กฎ
เชื่อมโยง
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
คำเตือน: ไม่แนะนำให้ใช้ bind() ดู "พิจารณานำการเชื่อมโยงออก" เป็นเวลานาน
การอภิปรายเกี่ยวกับประเด็นและทางเลือก โดยเฉพาะอย่างยิ่ง โปรดพิจารณาการใช้
repo_mapping
แอตทริบิวต์ของที่เก็บ
คำเตือน: select() ไม่สามารถใช้ใน bind() ดูคำถามที่พบบ่อยเกี่ยวกับแอตทริบิวต์ที่กำหนดค่าได้สำหรับ
รายละเอียด
กำหนดชื่อแทนให้เป้าหมายในแพ็กเกจ //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 โดยไม่ต้องแก้ไข
นอกจากนี้ยังใช้การเชื่อมโยงเพื่อทำให้เป้าหมายในที่เก็บภายนอกพร้อมใช้งานในพื้นที่ทำงานของคุณได้ด้วย
เช่น หากมีการนำเข้าที่เก็บระยะไกลชื่อ @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"
อาร์กิวเมนต์
| Attributes | |
|---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
actual
|
เป้าหมายนี้ต้องมีอยู่ แต่เป็นกฎประเภทใดก็ได้ (รวมถึงการเชื่อมโยง) หากละเว้นแอตทริบิวต์นี้ กฎที่อ้างถึงเป้าหมายนี้ใน |
local_repository
local_repository(name, path, repo_mapping)
อนุญาตให้เชื่อมโยงเป้าหมายจากไดเรกทอรีในเครื่อง ซึ่งหมายความว่าที่เก็บปัจจุบันจะทำสิ่งต่อไปนี้ได้ ใช้เป้าหมายที่ระบุไว้ในไดเรกทอรีอื่นนี้ ดูการเชื่อมโยง เพื่อดูรายละเอียดเพิ่มเติม
ตัวอย่าง
สมมติว่าที่เก็บปัจจุบันเป็นไคลเอ็นต์แชทที่รูทที่ไดเรกทอรี ~/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 เพื่ออ้างอิงข้อมูลนี้
ไลบรารี
อาร์กิวเมนต์
| Attributes | |
|---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
path
|
ต้องเป็นเส้นทางไปยังไดเรกทอรีที่มีที่เก็บของ WORKSPACE เส้นทางอาจเป็นแบบสัมบูรณ์หรือสัมพัทธ์กับที่เก็บหลัก WORKSPACE |
repo_mapping
|
ตัวอย่างเช่น รายการ |
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
อนุญาตให้เปลี่ยนไดเรกทอรีในเครื่องเป็นที่เก็บ Bazel ซึ่งหมายความว่า สามารถกำหนดและใช้เป้าหมายได้จากทุกที่ในระบบไฟล์
กฎนี้สร้างที่เก็บ Bazel โดยการสร้างไฟล์ WORKSPACE และไดเรกทอรีย่อยที่มี
symlink ไปยังไฟล์ 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
อาร์กิวเมนต์
| Attributes | |
|---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
build_file
|
ต้องระบุ create_file หรือbuild_file_content แอตทริบิวต์นี้เป็นป้ายกำกับที่เกี่ยวข้องกับพื้นที่ทำงานหลัก ไฟล์ไม่จำเป็นต้อง ชื่อ BUILD แต่สามารถเป็นได้ (ชื่อเช่น BUILD.new-repo-name อาจเหมาะสำหรับ เพื่อแยกออกจากไฟล์ BUILD จริงของที่เก็บ) |
build_file_content
|
ต้องระบุ create_file หรือbuild_file_content |
path
|
ซึ่งอาจเป็นแบบสัมบูรณ์หรือสัมพัทธ์กับไฟล์ WORKSPACE ของที่เก็บหลัก |
repo_mapping
|
ตัวอย่างเช่น รายการ |
workspace_file
|
คุณสามารถระบุ workspace_file หรือ workspace_file_content ได้ แต่ระบุทั้ง 2 รายการไม่ได้ แอตทริบิวต์นี้เป็นป้ายกำกับที่เกี่ยวข้องกับพื้นที่ทำงานหลัก ไฟล์ไม่จำเป็นต้อง ชื่อ WORKSPACE แต่สามารถเป็นได้ (ตัวอย่างชื่อ WORKSPACE.new-repo-name อาจเหมาะกับกรณีต่อไปนี้ เพื่อแยกออกจากไฟล์ WORKSPACE จริงของที่เก็บ) |
workspace_file_content
|
คุณสามารถระบุ workspace_file หรือ workspace_file_content ได้ แต่ระบุทั้ง 2 รายการไม่ได้ |