กฎ Workspace จะใช้เพื่อดึงทรัพยากร 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"
อาร์กิวเมนต์
แอตทริบิวต์ | |
---|---|
name |
ชื่อที่ไม่ซ้ํากันสําหรับเป้าหมายนี้ |
actual
|
ต้องมีเป้าหมายนี้ แต่อาจเป็นกฎทุกประเภท (รวมถึงการเชื่อมโยง) หากไม่ระบุแอตทริบิวต์นี้ กฎที่อ้างถึงเป้าหมายนี้ใน |
ที่เก็บในเครื่อง
ดูแหล่งที่มาของกฎ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 เพื่ออยู่ในไลบรารีนี้
อาร์กิวเมนต์
แอตทริบิวต์ | |
---|---|
name |
ชื่อที่ไม่ซ้ํากันสําหรับเป้าหมายนี้ |
path
|
ต้องเป็นเส้นทางไปยังไดเรกทอรีที่มีไฟล์ WORKSPACE ของที่เก็บ เส้นทางอาจเป็นค่าสัมบูรณ์หรือสัมพัทธ์กับไฟล์ WORKSPACE ของที่เก็บหลัก |
repo_mapping
|
ตัวอย่างเช่น รายการ |
ที่เก็บในเครื่องใหม่
ดูแหล่งที่มาของกฎ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
|
ต้องระบุ build_file หรือ build_file_content แอตทริบิวต์นี้เป็นป้ายกํากับที่สัมพันธ์กับพื้นที่ทํางานหลัก ไฟล์ไม่จําเป็นต้องมีชื่อว่า BUILD แต่อาจเป็นได้ (เช่น BUILD.new-repo-name อาจเหมาะสําหรับการแยกความแตกต่างจากไฟล์ BUILD จริงของที่เก็บ) |
build_file_content
|
ต้องระบุ build_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 อย่างไม่ได้ |