สำหรับเอกสารรุ่นที่เสถียร โปรดใช้รายการแบบเลื่อนลง "เอกสารที่มีเวอร์ชัน" มุมมองเริ่มต้นจะแสดงเวอร์ชันล่าสุดที่ HEAD

หน้านี้ได้รับการแปลโดย Cloud Translation API

กฎของ Workspace

กฎ 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

Name; required

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

actual

Label; optional

เป้าหมายที่จะใช้เป็นชื่อแทน

ต้องมีเป้าหมายนี้ แต่อาจเป็นกฎทุกประเภท (รวมถึงการเชื่อมโยง)

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

ที่เก็บในเครื่อง

ดูแหล่งที่มาของกฎ

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

Name; required

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

path

String; required

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

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

repo_mapping

Dictionary: String -> String; optional

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

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

ที่เก็บในเครื่องใหม่

ดูแหล่งที่มาของกฎ

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`	`Name; required` ชื่อที่ไม่ซ้ํากันสําหรับเป้าหมายนี้
`build_file`	`String; optional` ไฟล์ที่จะใช้เป็นไฟล์ BUILD สําหรับไดเรกทอรีนี้ ต้องระบุ build_file หรือ build_file_content แอตทริบิวต์นี้เป็นป้ายกํากับที่สัมพันธ์กับพื้นที่ทํางานหลัก ไฟล์ไม่จําเป็นต้องมีชื่อว่า BUILD แต่อาจเป็นได้ (เช่น BUILD.new-repo-name อาจเหมาะสําหรับการแยกความแตกต่างจากไฟล์ BUILD จริงของที่เก็บ)
`build_file_content`	`String; optional` เนื้อหาของไฟล์ BUILD สําหรับที่เก็บนี้ ต้องระบุ build_file หรือ build_file_content
`path`	`String; required` เส้นทางในระบบไฟล์ในเครื่อง อาจเป็นได้ทั้งสัมบูรณ์หรือสัมพัทธ์กับไฟล์ WORKSPACE ของที่เก็บหลัก
`repo_mapping`	`Dictionary: String -> String; optional` พจนานุกรมจากชื่อที่เก็บในเครื่องไปยังชื่อที่เก็บส่วนกลาง การดําเนินการนี้จะช่วยให้ควบคุมการแปลงทรัพยากร Dependency ของทรัพยากร Dependency ของที่เก็บนี้ได้ ตัวอย่างเช่น รายการ `"@foo": "@bar"` ประกาศว่าเมื่อใดที่ที่เก็บนี้จะขึ้นอยู่กับ `"@foo"` (เช่น ทรัพยากร Dependency ใน `"@foo//some:target"`) ระบบควรแก้ไขทรัพยากร Dependency นั้นภายใน `"@bar"` (`"@bar//some:target"`) ที่ประกาศทั่วโลก
`workspace_file`	`String; optional` ไฟล์ที่จะใช้เป็นไฟล์ WORKSPACE สําหรับที่เก็บนี้ ระบุ workspace_file หรือ workspace_file_content ได้ แต่ระบุทั้ง 2 อย่างไม่ได้ แอตทริบิวต์นี้เป็นป้ายกํากับที่สัมพันธ์กับพื้นที่ทํางานหลัก ไฟล์ไม่จําเป็นต้องมีชื่อว่า WORKSPACE แต่อาจเป็นได้ (เช่น WORKSPACE.new-repo-name อาจเหมาะสําหรับการแยกความแตกต่างจากไฟล์ WORKSPACE จริงของที่เก็บ)
`workspace_file_content`	`String; optional` เนื้อหาของไฟล์ WORKSPACE สําหรับที่เก็บนี้ ระบุ workspace_file หรือ workspace_file_content ได้ แต่ระบุทั้ง 2 อย่างไม่ได้