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

รายงานปัญหา ดูซอร์สโค้ด รุ่น Nightly · 8.0 7.4 7.3 · 7.2 · 7.1 · 7.0 · 6.5

ระบบจะใช้กฎของพื้นที่ทํางานเพื่อดึงทรัพยากรภายนอก ซึ่งโดยทั่วไปแล้วคือซอร์สโค้ดที่อยู่นอกที่เก็บข้อมูลหลัก

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

กฎ

• bind
• local_repository
• new_local_repository

เชื่อมโยง

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

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 โดยที่ไม่ต้องแก้ไข

นอกจากนี้ คุณยังใช้การเชื่อมโยงเพื่อทําให้เป้าหมายในที่เก็บข้อมูลภายนอกพร้อมใช้งานใน Workspace ได้ด้วย ตัวอย่างเช่น หากมีที่เก็บระยะไกลชื่อ @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	ป้ายกํากับ ค่าเริ่มต้นคือ None เป้าหมายที่จะตั้งชื่อแทน เป้าหมายนี้ต้องมีอยู่ แต่อาจเป็นกฎประเภทใดก็ได้ (รวมถึงการเชื่อมโยง) หากไม่ระบุแอตทริบิวต์นี้ กฎที่อ้างอิงเป้าหมายนี้ใน //external ก็จะไม่เห็นขอบความเกี่ยวข้องนี้ โปรดทราบว่าการดำเนินการนี้แตกต่างจากการละเว้นกฎ bind ทั้งหมด เนื่องจากระบบจะแสดงข้อผิดพลาดหากข้อกำหนด //external ที่ไม่มีกฎ bind ที่เชื่อมโยง

local_repository

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

local_repository(name, path, repo_mapping)

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

ตัวอย่าง

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

ผู้ใช้สามารถเพิ่มการพึ่งพาเป้าหมายนี้ได้โดยการเพิ่มบรรทัดต่อไปนี้ลงใน ~/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	พจนานุกรม: สตริง -> สตริง ค่าเริ่มต้นคือ {} พจนานุกรมจากชื่อที่เก็บในเครื่องเป็นชื่อที่เก็บส่วนกลาง ซึ่งช่วยให้ควบคุมการแก้ไขข้อกำหนดของพื้นที่ทำงานสำหรับข้อกำหนดของที่เก็บข้อมูลนี้ได้ ตัวอย่างเช่น รายการ "@foo": "@bar" ประกาศว่าเมื่อใดก็ตามที่ที่เก็บข้อมูลนี้ใช้ "@foo" (เช่น ใช้ "@foo//some:target") ก็ควรแก้ไขการพึ่งพานั้นภายใน "@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

ผู้ใช้สามารถเพิ่มข้อกำหนดโดยสร้างไฟล์ 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 ลงในข้อกําหนดของเป้าหมาย

นอกจากนี้ คุณยังใช้ 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	ชื่อ ค่าเริ่มต้นคือ 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	พจนานุกรม: สตริง -> สตริง ค่าเริ่มต้นคือ {} พจนานุกรมจากชื่อที่เก็บในเครื่องเป็นชื่อที่เก็บส่วนกลาง ซึ่งช่วยให้ควบคุมการแก้ไขข้อกำหนดของพื้นที่ทำงานสำหรับข้อกำหนดของที่เก็บข้อมูลนี้ได้ ตัวอย่างเช่น รายการ "@foo": "@bar" ประกาศว่าเมื่อใดก็ตามที่ที่เก็บข้อมูลนี้ใช้ "@foo" (เช่น ใช้ "@foo//some:target") ก็ควรแก้ไขการพึ่งพานั้นภายใน "@bar" ("@bar//some:target") ที่ประกาศไว้ทั่วโลก
workspace_file	ชื่อ ค่าเริ่มต้นคือ None ไฟล์ที่จะใช้เป็นไฟล์ WORKSPACE สําหรับที่เก็บข้อมูลนี้ คุณสามารถระบุ workspace_file หรือ workspace_file_content เพียงรายการใดรายการหนึ่ง แอตทริบิวต์นี้เป็นป้ายกำกับที่เกี่ยวข้องกับพื้นที่ทํางานหลัก ไฟล์ไม่จำเป็นต้องมีชื่อว่า WORKSPACE แต่สามารถตั้งชื่อเป็นเช่นนั้นได้ (ชื่ออย่าง WORKSPACE.new-repo-name อาจเหมาะที่จะใช้เพื่อแยกความแตกต่างจากไฟล์ WORKSPACE จริงของที่เก็บ)
workspace_file_content	สตริง ค่าเริ่มต้นคือ "" เนื้อหาสำหรับไฟล์ WORKSPACE ของที่เก็บข้อมูลนี้ คุณสามารถระบุ workspace_file หรือ workspace_file_content เพียงรายการใดรายการหนึ่ง