Các phương pháp hay nhất

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Báo cáo vấn đề Xem nguồn

Trang này giả định rằng bạn đã quen thuộc với Bazel và đưa ra hướng dẫn cũng như lời khuyên về cách xây dựng cấu trúc cho các dự án của bạn để tận dụng tối đa các tính năng của Bazel.

Các mục tiêu tổng thể là:

  • Sử dụng các phần phụ thuộc chi tiết để cho phép tải song song và mức độ gia tăng.
  • Để các phần phụ thuộc được đóng gói tốt.
  • Làm cho mã có cấu trúc tốt và có thể kiểm thử được.
  • Tạo cấu hình bản dựng dễ hiểu và dễ duy trì.

Các nguyên tắc này không phải là yêu cầu: rất ít dự án có thể tuân thủ tất cả các yêu cầu này. Như trang người dùng của công cụ tìm lỗi mã nguồn nói, "Một phần thưởng đặc biệt sẽ được tặng cho người đầu tiên tạo ra một chương trình thực tế mà không gây ra lỗi kiểm tra nghiêm ngặt". Tuy nhiên, việc kết hợp càng nhiều nguyên tắc càng tốt sẽ giúp dự án dễ đọc hơn, ít xảy ra lỗi hơn và nhanh hơn để xây dựng.

Trang này sử dụng các cấp yêu cầu như mô tả trong RFC này.

Chạy bản dựng và kiểm thử

Một dự án phải luôn có thể chạy thành công bazel build //...bazel test //... trên nhánh ổn định của dự án đó. Các mục tiêu cần thiết nhưng không xây dựng trong một số trường hợp nhất định (chẳng hạn như yêu cầu cờ xây dựng cụ thể, không tạo trên nền tảng nhất định, yêu cầu thỏa thuận cấp phép) phải được gắn thẻ cụ thể nhất có thể (ví dụ: "requires-osx"). Việc gắn thẻ này cho phép lọc các mục tiêu ở mức độ chi tiết hơn thẻ "thủ công" và cho phép người kiểm tra tệp BUILD hiểu rõ các giới hạn của mục tiêu.

Phần phụ thuộc của bên thứ ba

Bạn có thể khai báo các phần phụ thuộc của bên thứ ba:

  • Hãy khai báo tệp này dưới dạng kho lưu trữ từ xa trong tệp WORKSPACE.
  • Bạn cũng có thể đặt các thư mục này vào một thư mục có tên là third_party/ trong thư mục của Workspace.

Tùy thuộc vào tệp nhị phân

Bạn phải xây dựng mọi thứ từ nguồn bất cứ khi nào có thể. Nhìn chung, điều này có nghĩa là thay vì phụ thuộc vào một thư viện some-library.so, bạn sẽ tạo tệp BUILD và tạo some-library.so từ các nguồn của thư viện đó, sau đó phụ thuộc vào mục tiêu đó.

Việc luôn tạo từ nguồn đảm bảo rằng bản dựng không sử dụng thư viện được tạo bằng các cờ không tương thích hoặc cấu trúc khác. Ngoài ra, một số tính năng như phạm vi bao phủ, phân tích tĩnh hoặc phân tích động chỉ hoạt động trên nguồn.

Lập phiên bản.

Ưu tiên tạo tất cả mã từ đầu bất cứ khi nào có thể. Khi phải sử dụng các phiên bản, hãy tránh đưa phiên bản vào tên mục tiêu (ví dụ: //guava, chứ không phải //guava-20.0). Cách đặt tên này giúp thư viện dễ cập nhật hơn (chỉ cần cập nhật một mục tiêu). Ngoài ra còn linh hoạt hơn về các vấn đề phụ thuộc kim cương: nếu một thư viện phụ thuộc vào guava-19.0 và một thư viện phụ thuộc vào guava-20.0, thì bạn có thể kết thúc bằng một thư viện cố gắng phụ thuộc vào hai phiên bản khác nhau. Nếu bạn đã tạo một bí danh gây hiểu lầm để trỏ cả hai mục tiêu đến một thư viện guava, thì các tệp BUILD sẽ gây hiểu lầm.

Sử dụng tệp .bazelrc

Để biết các tùy chọn dành riêng cho dự án, hãy sử dụng tệp cấu hình workspace/.bazelrc của bạn (xem định dạng blog).

Nếu bạn muốn hỗ trợ các tuỳ chọn cho mỗi người dùng cho dự án mà bạn không muốn kiểm tra trong chế độ kiểm soát nguồn, hãy thêm dòng:

try-import %workspace%/user.bazelrc

(hoặc bất kỳ tên tệp nào khác) trong workspace/.bazelrc và thêm user.bazelrc vào .gitignore.

Gói

Mọi thư mục chứa tệp có thể tạo đều phải là gói. Nếu tệp BUILD tham chiếu đến các tệp trong thư mục con (chẳng hạn như srcs = ["a/b/C.java"]), thì đó là dấu hiệu cho thấy bạn nên thêm tệp BUILD vào thư mục con đó. Cấu trúc này càng tồn tại thì càng có nhiều khả năng phụ thuộc vòng tròn được tạo vô tình, phạm vi của mục tiêu sẽ kéo dài và số lượng phần phụ thuộc đảo ngược ngày càng tăng phải được cập nhật.