Bazel có thể phụ thuộc vào mục tiêu của các dự án khác. Các phần phụ thuộc của những dự án khác này được gọi là phần phụ thuộc bên ngoài.
Tệp WORKSPACE
(hoặc tệp WORKSPACE.bazel
) trong
thư mục không gian làm việc
cho Bazel biết cách lấy các nguồn của các dự án khác. Các dự án khác này có thể chứa một hoặc nhiều tệp BUILD
có mục tiêu riêng. Các tệp BUILD
trong dự án chính có thể phụ thuộc vào các mục tiêu bên ngoài này bằng cách dùng tên của các mục tiêu đó trong tệp WORKSPACE
.
Ví dụ: giả sử có hai dự án trên một hệ thống:
/
home/
user/
project1/
WORKSPACE
BUILD
srcs/
...
project2/
WORKSPACE
BUILD
my-libs/
Nếu project1
muốn phụ thuộc vào một mục tiêu :foo
được xác định trong /home/user/project2/BUILD
, thì lớp này có thể chỉ định rằng kho lưu trữ có tên là project2
có thể được tìm thấy tại /home/user/project2
. Khi đó, các mục tiêu trong /home/user/project1/BUILD
có thể phụ thuộc vào @project2//:foo
.
Tệp WORKSPACE
cho phép người dùng phụ thuộc vào các mục tiêu từ các phần khác của hệ thống tệp hoặc được tải xuống từ Internet. Tệp này sử dụng cú pháp giống như tệp BUILD
, nhưng cho phép sử dụng một bộ quy tắc khác được gọi là quy tắc kho lưu trữ (đôi khi còn gọi là quy tắc không gian làm việc). Bazel đi kèm một số quy tắc về kho lưu trữ tích hợp sẵn và bộ quy tắc về kho lưu trữ Starlark được nhúng.
Người dùng cũng có thể viết các quy tắc kho lưu trữ tuỳ chỉnh để có được hành vi phức tạp hơn.
Các loại phần phụ thuộc bên ngoài được hỗ trợ
Bạn có thể sử dụng một số kiểu phần phụ thuộc bên ngoài cơ bản sau:
- Phần phụ thuộc vào các dự án Bazel khác
- Phần phụ thuộc vào các dự án không phải Bazel
- Phần phụ thuộc vào gói bên ngoài
Tuỳ thuộc vào các dự án khác của Bazel
Nếu muốn sử dụng các mục tiêu từ dự án Bazel thứ hai, bạn có thể sử dụng local_repository
, git_repository
hoặc http_archive
để liên kết tượng trưng từ hệ thống tệp cục bộ, tham chiếu kho lưu trữ git hoặc tải xuống (tương ứng).
Ví dụ: giả sử bạn đang thực hiện một dự án my-project/
và muốn phụ thuộc vào các mục tiêu trong dự án coworkers-project/
của một đồng nghiệp. Cả hai dự án đều sử dụng Bazel, vì vậy, bạn có thể thêm dự án của đồng nghiệp dưới dạng phần phụ thuộc bên ngoài, sau đó sử dụng bất kỳ mục tiêu nào mà đồng nghiệp của bạn đã xác định từ tệp XÂY DỰNG của riêng bạn. Bạn sẽ thêm đoạn mã sau vào my_project/WORKSPACE
:
local_repository(
name = "coworkers_project",
path = "/path/to/coworkers-project",
)
Nếu đồng nghiệp của bạn có một //foo:bar
mục tiêu, thì dự án của bạn có thể gọi đó là @coworkers_project//foo:bar
. Tên dự án bên ngoài phải là tên không gian làm việc hợp lệ.
Tuỳ thuộc vào các dự án không phải Bazel
Các quy tắc có tiền tố new_
, chẳng hạn như new_local_repository
, cho phép bạn tạo mục tiêu từ các dự án không sử dụng Bazel.
Ví dụ: giả sử bạn đang thực hiện một dự án, my-project/
và muốn phụ thuộc vào dự án coworkers-project/
của đồng nghiệp. Dự án của một đồng nghiệp sử dụng make
để xây dựng, nhưng bạn muốn phụ thuộc vào một trong các tệp .so mà đồng nghiệp tạo ra. Để thực hiện việc này, hãy thêm nội dung sau vào my_project/WORKSPACE
:
new_local_repository(
name = "coworkers_project",
path = "/path/to/coworkers-project",
build_file = "coworker.BUILD",
)
build_file
chỉ định một tệp BUILD
để phủ lên dự án hiện có, ví dụ:
cc_library(
name = "some-lib",
srcs = glob(["**"]),
visibility = ["//visibility:public"],
)
Sau đó, bạn có thể phụ thuộc vào @coworkers_project//:some-lib
từ các tệp BUILD
của dự án.
Tuỳ thuộc vào các gói bên ngoài
Cấu phần phần mềm và kho lưu trữ Maven
Sử dụng bộ quy tắc rules_jvm_external
để tải cấu phần phần mềm xuống từ kho lưu trữ Maven và cung cấp các cấu phần phần mềm đó dưới dạng phần phụ thuộc Java.
Đang tìm nạp phần phụ thuộc
Theo mặc định, các phần phụ thuộc bên ngoài sẽ được tìm nạp khi cần trong bazel build
. Nếu bạn muốn tìm nạp trước các phần phụ thuộc cần thiết cho một nhóm mục tiêu cụ thể, hãy sử dụng bazel fetch
.
Để tìm nạp vô điều kiện tất cả phần phụ thuộc bên ngoài, hãy sử dụng bazel sync
.
Vì các kho lưu trữ đã tìm nạp được lưu trữ trong cơ sở dữ liệu đầu ra, nên việc tìm nạp sẽ diễn ra theo từng không gian làm việc.
Các phần phụ thuộc đổ bóng
Bất cứ khi nào có thể, bạn nên có một chính sách phiên bản duy nhất trong dự án của mình. Đây là yêu cầu bắt buộc đối với các phần phụ thuộc mà bạn biên dịch và đưa vào tệp nhị phân cuối cùng. Tuy nhiên, trong trường hợp không đúng, bạn có thể ẩn các phần phụ thuộc. Hãy xem xét trường hợp sau:
myproject/WORKSPACE
workspace(name = "myproject")
local_repository(
name = "A",
path = "../A",
)
local_repository(
name = "B",
path = "../B",
)
A/WORKSPACE
workspace(name = "A")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "testrunner",
urls = ["https://github.com/testrunner/v1.zip"],
sha256 = "...",
)
B/WORKSPACE
workspace(name = "B")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "testrunner",
urls = ["https://github.com/testrunner/v2.zip"],
sha256 = "..."
)
Cả hai phần phụ thuộc A
và B
đều phụ thuộc vào testrunner
, nhưng lại phụ thuộc vào các phiên bản khác nhau của testrunner
. Không có lý do nào để các trình chạy kiểm thử này không cùng tồn tại một cách yên bình trong myproject
. Tuy nhiên, chúng sẽ xung đột với nhau vì có cùng tên. Để khai báo cả hai phần phụ thuộc, hãy cập nhật myproject/WORKSPACE:
workspace(name = "myproject")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "testrunner-v1",
urls = ["https://github.com/testrunner/v1.zip"],
sha256 = "..."
)
http_archive(
name = "testrunner-v2",
urls = ["https://github.com/testrunner/v2.zip"],
sha256 = "..."
)
local_repository(
name = "A",
path = "../A",
repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
name = "B",
path = "../B",
repo_mapping = {"@testrunner" : "@testrunner-v2"}
)
Cơ chế này cũng có thể dùng để kết hợp kim cương. Ví dụ: nếu A
và B
có cùng phần phụ thuộc nhưng gọi bằng tên khác, thì bạn có thể kết hợp các phần phụ thuộc đó trong myproject/WORKSPACE.
Ghi đè kho lưu trữ từ dòng lệnh
Để ghi đè một kho lưu trữ đã khai báo bằng một kho lưu trữ cục bộ từ dòng lệnh, hãy sử dụng cờ --override_repository
. Việc sử dụng cờ này sẽ thay đổi nội dung của các kho lưu trữ bên ngoài mà không thay đổi mã nguồn.
Ví dụ: để ghi đè @foo
vào thư mục cục bộ /path/to/local/foo
, hãy chuyển cờ --override_repository=foo=/path/to/local/foo
.
Sau đây là một số trường hợp sử dụng:
- Gỡ lỗi cho vấn đề. Ví dụ: bạn có thể ghi đè kho lưu trữ
http_archive
thành một thư mục cục bộ để có thể thực hiện thay đổi dễ dàng hơn. - Nhà cung cấp. Nếu bạn đang ở trong một môi trường không thể thực hiện lệnh gọi mạng, hãy ghi đè các quy tắc về kho lưu trữ dựa trên mạng để trỏ đến các thư mục cục bộ.
Sử dụng proxy
Bazel sẽ nhận địa chỉ proxy từ các biến môi trường HTTPS_PROXY
và HTTP_PROXY
, đồng thời sử dụng các biến này để tải các tệp HTTP/HTTPS xuống (nếu được chỉ định).
Hỗ trợ cho IPv6
Trên các máy chỉ hỗ trợ IPv6, Bazel sẽ có thể tải các phần phụ thuộc xuống mà không cần thay đổi. Tuy nhiên, trên các máy IPv4/IPv6 ngăn xếp kép, Bazel tuân theo cùng một quy ước như Java: nếu IPv4 được bật, IPv4 sẽ được ưu tiên. Trong một số trường hợp, chẳng hạn như khi mạng IPv4 không thể phân giải/truy cập vào các địa chỉ bên ngoài, điều này có thể gây ra các trường hợp ngoại lệ Network unreachable
và lỗi bản dựng.
Trong những trường hợp này, bạn có thể ghi đè hành vi của Bazel để ưu tiên IPv6 bằng cách sử dụng thuộc tính hệ thống java.net.preferIPv6Addresses=true
.
Cụ thể:
Sử dụng tuỳ chọn khởi động
--host_jvm_args=-Djava.net.preferIPv6Addresses=true
, chẳng hạn như bằng cách thêm dòng sau vào tệp.bazelrc
:startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true
Nếu bạn đang chạy các mục tiêu bản dựng Java cũng cần kết nối với Internet (đôi khi cần kiểm thử tích hợp), bạn cũng nên sử dụng cờ công cụ
--jvmopt=-Djava.net.preferIPv6Addresses=true
, chẳng hạn như bằng cách thêm dòng sau trong tệp.bazelrc
:build --jvmopt=-Djava.net.preferIPv6Addresses
Nếu bạn đang sử dụng rules_jvm_external, chẳng hạn như để phân giải phiên bản phần phụ thuộc, hãy thêm
-Djava.net.preferIPv6Addresses=true
vào biến môi trườngCOURSIER_OPTS
để cung cấp các tuỳ chọn JVM cho Coursier
Phần phụ thuộc bắc cầu
Bazel chỉ đọc các phần phụ thuộc được liệt kê trong tệp WORKSPACE
. Nếu dự án của bạn (A
) phụ thuộc vào một dự án khác (B
) có liệt kê phần phụ thuộc trên dự án thứ ba (C
) trong tệp WORKSPACE
của dự án đó, thì bạn sẽ phải thêm cả B
và C
vào tệp WORKSPACE
của dự án. Yêu cầu này có thể tăng kích thước tệp WORKSPACE
, nhưng giới hạn khả năng một thư viện sẽ chứa C
ở phiên bản 1.0 và một thư viện khác bao gồm C
ở phiên bản 2.0.
Lưu các phần phụ thuộc bên ngoài vào bộ nhớ đệm
Theo mặc định, Bazel sẽ chỉ tải lại các phần phụ thuộc bên ngoài xuống nếu định nghĩa của các phần đó thay đổi. Bazel cũng xem xét các thay đổi đối với các tệp được tham chiếu trong định nghĩa (chẳng hạn như bản vá hoặc tệp BUILD
).
Để buộc tải xuống lại, hãy sử dụng bazel sync
.
Bố cục
Tất cả phần phụ thuộc bên ngoài đều được tải xuống một thư mục trong thư mục con external
trong cơ sở đầu ra. Đối với
kho lưu trữ cục bộ, một đường liên kết tượng trưng sẽ được tạo
ở đó thay vì tạo một thư mục mới.
Bạn có thể xem thư mục external
bằng cách chạy:
ls $(bazel info output_base)/external
Xin lưu ý rằng việc chạy bazel clean
sẽ không thực sự xoá thư mục bên ngoài. Để xoá tất cả cấu phần phần mềm bên ngoài, hãy dùng bazel clean --expunge
.
Bản dựng ngoại tuyến
Đôi khi, việc chạy một bản dựng theo cách ngoại tuyến là cần thiết hoặc mong muốn. Đối với các trường hợp sử dụng đơn giản, chẳng hạn như di chuyển trên máy bay, bạn có thể tìm nạp trước các kho lưu trữ cần thiết bằng bazel fetch
hoặc bazel sync
; hơn nữa, nếu sử dụng tuỳ chọn --nofetch
, bạn có thể tắt tính năng tìm nạp thêm các kho lưu trữ khác trong quá trình tạo bản dựng.
Đối với các bản dựng ngoại tuyến thực, trong đó việc cung cấp các tệp cần thiết do một thực thể khác với bazel thực hiện, bazel sẽ hỗ trợ tuỳ chọn --distdir
. Bất cứ khi nào quy tắc kho lưu trữ yêu cầu bazel tìm nạp tệp qua ctx.download
hoặc ctx.download_and_extract
và cung cấp tổng hàm băm của tệp cần thiết, trước tiên, bazel sẽ xem xét các thư mục do tuỳ chọn đó chỉ định để tìm một tệp khớp với tên cơ sở của URL đầu tiên được cung cấp và sử dụng bản sao cục bộ đó nếu hàm băm khớp.
Chính Bazel sử dụng kỹ thuật này để tự khởi động khi không có mạng từ cấu phần phần mềm phân phối.
Thư viện này thực hiện việc này bằng cách thu thập tất cả phần phụ thuộc bên ngoài cần thiết trong một distdir_tar
nội bộ.
Tuy nhiên, bazel cho phép thực thi các lệnh tuỳ ý trong các quy tắc kho lưu trữ mà không cần biết các lệnh đó có gọi mạng hay không. Do đó, bazel không có cách nào để thực thi các bản dựng hoàn toàn không có mạng. Vì vậy, việc kiểm thử xem một bản dựng có hoạt động chính xác khi không có mạng hay không yêu cầu phải chặn mạng bên ngoài, như cách bazel thực hiện trong kiểm thử khởi động dây đeo.
Các phương pháp hay nhất
Quy tắc kho lưu trữ
Quy tắc kho lưu trữ thường phải chịu trách nhiệm về:
- Phát hiện chế độ cài đặt hệ thống và ghi vào tệp.
- Đang tìm tài nguyên ở nơi khác trong hệ thống.
- Đang tải tài nguyên xuống từ các URL.
- Tạo hoặc liên kết tệp BUILD trong thư mục kho lưu trữ bên ngoài.
Tránh sử dụng repository_ctx.execute
khi có thể. Ví dụ: khi sử dụng thư viện C++ không phải Bazel có bản dựng bằng Make, bạn nên sử dụng repository_ctx.download()
rồi ghi tệp BUILD để tạo bản dựng đó, thay vì chạy ctx.execute(["make"])
.
Ưu tiên http_archive
hơn git_repository
và new_git_repository
. Lý do là:
- Các quy tắc kho lưu trữ Git phụ thuộc vào hệ thống
git(1)
trong khi trình tải xuống HTTP được tích hợp vào Bazel và không có phần phụ thuộc hệ thống. http_archive
hỗ trợ danh sáchurls
làm bản sao vàgit_repository
chỉ hỗ trợ mộtremote
duy nhất.http_archive
hoạt động với bộ nhớ đệm của kho lưu trữ, nhưng không hoạt động vớigit_repository
. Vui lòng xem #5116 để biết thêm thông tin.
Đừng sử dụng bind()
. Hãy xem phần "Cân nhắc xoá liên kết" để thảo luận dài về các vấn đề và lựa chọn thay thế.