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

Báo cáo vấn đề Xem nguồn Hằng đêm · 7,3 · 7.2 · 7.1 · 7 · 6,5

Trang này giả định rằng bạn đã quen thuộc với Bazel, đồng thời đưa ra các nguyên tắc và lời khuyên về cấu trúc dự án của bạn để tận dụng tối đa các tính năng của Bazel.

Mục tiêu chung là:

  • Để sử dụng các phần phụ thuộc chi tiết nhằm cho phép tính song song và gia tăng.
  • Để đóng gói các phần phụ thuộc một cách hiệu quả.
  • Để mã có cấu trúc hợp lý và dễ kiểm thử.
  • Để tạo một cấu hình bản dựng dễ hiểu và dễ duy trì.

Đây không phải là những nguyên tắc bắt buộc nên một số dự án sẽ có thể tuân thủ tất cả các nguyên tắc đó. Như trang man cho lint (tìm lỗi mã nguồn) cho biết: "Bạn sẽ nhận được một phần thưởng đặc biệt cho người đầu tiên tạo ra một chương trình thực tế không gây ra lỗi nào vớ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 trong số này càng tốt sẽ làm cho dự án dễ đọc hơn, ít gặp lỗi hơn và xây dựng nhanh hơn.

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

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

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

Các 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:

  • Khai báo các kho lưu trữ đó dưới dạng kho lưu trữ từ xa trong tệp WORKSPACE.
  • Bạn cũng có thể chuyển các tệp này vào một thư mục có tên là third_party/ trong thư mục không gian làm việc.

Tuỳ thuộc vào tệp nhị phân

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

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

Lập phiên bản

Ưu tiên tạo toàn bộ mã từ đầu bất cứ khi nào có thể. Trường hợp phiên bản phải được sử dụng, 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 cập nhật thư viện dễ dàng hơn (chỉ một mục tiêu cần được cập nhật). Ngoài ra, mã này cũng thích ứng hơn với sự phụ thuộc về kim cương vấn đề: 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, bạn có thể sẽ tạo ra một thư viện 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ì tệp BUILD gây hiểu lầm.

Sử dụng tệp .bazelrc

Đối với các lựa chọn dành riêng cho dự án, hãy sử dụng tệp cấu hình workspace/.bazelrc (xem định dạng Bazelrc).

Nếu bạn muốn hỗ trợ các lựa chọn cho mỗi người dùng cho dự án mà bạn không muốn kiểm tra phần 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 của bạn và thêm user.bazelrc vào .gitignore của bạn.

Gói

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