Di chuyển từ Xcode sang Bazel

Báo cáo vấn đề Xem nguồn Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Trang này mô tả cách tạo hoặc thử nghiệm dự án Xcode bằng Bazel. Tài liệu này mô tả sự khác biệt giữa Xcode và Bazel, đồng thời cung cấp các bước để chuyển đổi dự án Xcode sang dự án Bazel. Tài liệu này cũng cung cấp các giải pháp khắc phục sự cố để giải quyết các lỗi thường gặp.

Sự khác biệt giữa Xcode và Bazel

  • Bazel yêu cầu bạn chỉ định rõ ràng mọi mục tiêu bản dựng và các phần phụ thuộc của bản dựng đó, cùng với các chế độ cài đặt bản dựng tương ứng thông qua các quy tắc bản dựng.

  • Bazel yêu cầu tất cả các tệp mà dự án phụ thuộc phải có trong thư mục không gian làm việc hoặc được chỉ định là tệp nhập trong tệp WORKSPACE.

  • Khi tạo dự án Xcode bằng Bazel, (các) tệp BUILD sẽ trở thành nguồn đáng tin cậy. Nếu làm việc trên dự án trong Xcode, bạn phải tạo phiên bản mới của dự án Xcode khớp với các tệp BUILD bằng cách sử dụng Tulsi mỗi khi cập nhật tệp BUILD. Nếu bạn không sử dụng Xcode, các lệnh bazel buildbazel test sẽ cung cấp các tính năng xây dựng và kiểm thử với một số hạn chế nhất định được mô tả ở phần sau của hướng dẫn này.

  • Do sự khác biệt về giản đồ cấu hình bản dựng, chẳng hạn như bố cục thư mục hoặc cờ bản dựng, Xcode có thể không nhận biết được toàn bộ "bức tranh lớn" của bản dựng, do đó, một số tính năng của Xcode có thể không hoạt động. Cụ thể là:

    • Tuỳ thuộc vào các mục tiêu bạn chọn để chuyển đổi trong Tulsi, Xcode có thể không lập được chỉ mục nguồn dự án một cách chính xác. Điều này ảnh hưởng đến việc hoàn thành và điều hướng mã trong Xcode, vì Xcode sẽ không thể xem tất cả mã nguồn của dự án.

    • Tính năng phân tích tĩnh, trình dọn dẹp địa chỉ và trình dọn dẹp luồng có thể không hoạt động vì Bazel không tạo ra kết quả mà Xcode mong đợi cho các tính năng đó.

    • Nếu bạn tạo một dự án Xcode bằng Tulsi và sử dụng dự án đó để chạy các chương trình kiểm thử từ trong Xcode, thì Xcode sẽ chạy các chương trình kiểm thử thay vì Bazel. Để chạy kiểm thử bằng Bazel, hãy chạy lệnh bazel test theo cách thủ công.

Trước khi bắt đầu

Trước khi bắt đầu, hãy làm như sau:

  1. Cài đặt Bazel nếu bạn chưa cài đặt.

  2. Nếu bạn chưa quen với Bazel và các khái niệm của Bazel, hãy hoàn thành hướng dẫn về ứng dụng iOS. Bạn nên hiểu rõ không gian làm việc Bazel, bao gồm cả các tệp WORKSPACEBUILD, cũng như các khái niệm về mục tiêu, quy tắc xây dựng và gói Bazel.

  3. Phân tích và tìm hiểu các phần phụ thuộc của dự án.

Phân tích các phần phụ thuộc của dự án

Không giống như Xcode, Bazel yêu cầu bạn phải khai báo rõ ràng tất cả phần phụ thuộc cho mọi mục tiêu trong tệp BUILD.

Để biết thêm thông tin về các phần phụ thuộc bên ngoài, hãy xem phần Xử lý các phần phụ thuộc bên ngoài.

Tạo hoặc kiểm thử dự án Xcode bằng Bazel

Để tạo hoặc kiểm thử dự án Xcode bằng Bazel, hãy làm như sau:

  1. Tạo tệp WORKSPACE

  2. (Thử nghiệm) Tích hợp các phần phụ thuộc CocoaPods

  3. Tạo tệp BUILD:

    a. Thêm mục tiêu ứng dụng

    b. (Không bắt buộc) Thêm(các) mục tiêu kiểm thử

    c. Thêm(các) mục tiêu thư viện

  4. (Không bắt buộc) Chi tiết hoá bản dựng

  5. Chạy bản dựng

  6. Tạo dự án Xcode bằng Tulsi

Bước 1: Tạo tệp WORKSPACE

Tạo tệp WORKSPACE trong một thư mục mới. Thư mục này trở thành thư mục gốc của không gian làm việc Bazel. Nếu dự án không sử dụng phần phụ thuộc bên ngoài, thì tệp này có thể trống. Nếu dự án phụ thuộc vào các tệp hoặc gói không nằm trong một trong các thư mục của dự án, hãy chỉ định các phần phụ thuộc bên ngoài này trong tệp WORKSPACE.

Bước 2: (Thử nghiệm) Tích hợp các phần phụ thuộc CocoaPods

Để tích hợp các phần phụ thuộc CocoaPods vào không gian làm việc Bazel, bạn phải chuyển đổi các phần phụ thuộc đó thành gói Bazel như mô tả trong phần Chuyển đổi phần phụ thuộc CocoaPods.

Bước 3: Tạo tệp BUILD

Sau khi xác định không gian làm việc và các phần phụ thuộc bên ngoài, bạn cần tạo một tệp BUILD để Bazel biết cấu trúc dự án. Tạo tệp BUILD ở gốc không gian làm việc Bazel và định cấu hình tệp này để tạo bản dựng ban đầu của dự án như sau:

Mẹo: Để tìm hiểu thêm về các gói và các khái niệm khác của Bazel, hãy xem bài viết Không gian làm việc, gói và mục tiêu.

Bước 3a: Thêm mục tiêu ứng dụng

Thêm mục tiêu quy tắc macos_application hoặc ios_application. Mục tiêu này sẽ tạo gói ứng dụng macOS hoặc iOS tương ứng. Trong mục tiêu, hãy chỉ định ít nhất những thông tin sau:

  • bundle_id – mã nhận dạng gói (đường dẫn ngược DNS theo sau là tên ứng dụng) của tệp nhị phân.

  • provisioning_profile – hồ sơ cấp phép từ tài khoản Nhà phát triển Apple (nếu bạn tạo ứng dụng cho thiết bị iOS).

  • families (chỉ dành cho iOS) – liệu nên tạo ứng dụng cho iPhone, iPad hay cả hai.

  • infoplists – danh sách các tệp .plist để hợp nhất vào tệp Info.plist cuối cùng.

  • minimum_os_version – phiên bản macOS hoặc iOS tối thiểu mà ứng dụng hỗ trợ. Điều này đảm bảo Bazel tạo ứng dụng với các cấp độ API chính xác.

Bước 3b: (Không bắt buộc) Thêm(các) mục tiêu kiểm thử

Quy tắc bản dựng Apple của Bazel hỗ trợ chạy kiểm thử đơn vị dựa trên thư viện trên iOS và macOS, cũng như kiểm thử dựa trên ứng dụng trên macOS. Đối với các bài kiểm thử dựa trên ứng dụng trên iOS hoặc kiểm thử giao diện người dùng trên một trong hai nền tảng, Bazel sẽ tạo ra kết quả kiểm thử nhưng các bài kiểm thử phải chạy trong Xcode thông qua một dự án được tạo bằng Tulsi. Thêm mục tiêu kiểm thử như sau:

  • macos_unit_test để chạy kiểm thử đơn vị dựa trên thư viện và dựa trên ứng dụng trên macOS.

  • ios_unit_test để chạy kiểm thử đơn vị dựa trên thư viện trên iOS. Đối với các kiểm thử yêu cầu trình mô phỏng iOS, Bazel sẽ tạo kết quả kiểm thử nhưng không chạy kiểm thử. Bạn phải tạo một dự án Xcode bằng Tulsi và chạy các chương trình kiểm thử trong Xcode.

  • ios_ui_test để tạo đầu ra cần thiết cho việc chạy kiểm thử giao diện người dùng trong trình mô phỏng iOS bằng Xcode. Bạn phải tạo một dự án Xcode bằng Tulsi và chạy các chương trình kiểm thử trong Xcode. Bazel không thể chạy kiểm thử giao diện người dùng theo cách gốc.

Tối thiểu, hãy chỉ định một giá trị cho thuộc tính minimum_os_version. Mặc dù các thuộc tính đóng gói khác, chẳng hạn như bundle_identifierinfoplists, mặc định là các giá trị được sử dụng phổ biến nhất, nhưng hãy đảm bảo rằng các giá trị mặc định đó tương thích với dự án và điều chỉnh các giá trị đó nếu cần. Đối với các kiểm thử yêu cầu trình mô phỏng iOS, hãy chỉ định tên mục tiêu ios_application làm giá trị của thuộc tính test_host.

Bước 3c: Thêm(các) mục tiêu thư viện

Thêm một mục tiêu objc_library cho từng thư viện Target C và một mục tiêu swift_library cho mỗi thư viện Swift mà ứng dụng và/hoặc bài kiểm thử phụ thuộc vào đó.

Thêm các mục tiêu thư viện như sau:

  • Thêm các mục tiêu thư viện ứng dụng dưới dạng phần phụ thuộc vào các mục tiêu ứng dụng.

  • Thêm các mục tiêu thư viện kiểm thử làm phần phụ thuộc vào các mục tiêu kiểm thử.

  • Liệt kê các nguồn triển khai trong thuộc tính srcs.

  • Liệt kê các tiêu đề trong thuộc tính hdrs.

Để biết thêm thông tin về quy tắc bản dựng, hãy xem phần Quy tắc của Apple cho Bazel.

Tại thời điểm này, bạn nên kiểm thử bản dựng:

bazel build //:<application_target>

Bước 4: (Không bắt buộc) Phân tích chi tiết bản dựng

Nếu dự án có quy mô lớn hoặc khi dự án phát triển, hãy cân nhắc chia nhỏ dự án thành nhiều gói Bazel. Độ chi tiết cao hơn này mang lại:

  • Tăng mức độ gia tăng của bản dựng,

  • Tăng mức độ song song của các tác vụ bản dựng,

  • Giúp người dùng trong tương lai có thể duy trì hoạt động hiệu quả hơn,

  • Kiểm soát tốt hơn chế độ hiển thị mã nguồn trên các mục tiêu và gói. Điều này giúp ngăn chặn các vấn đề như thư viện chứa thông tin chi tiết về việc triển khai bị rò rỉ vào API công khai.

Mẹo chi tiết hoá dự án:

  • Đặt mỗi thư viện vào một gói Bazel riêng. Bắt đầu với những phần phụ thuộc yêu cầu ít phần phụ thuộc nhất và tiến dần lên cây phần phụ thuộc.

  • Khi bạn thêm tệp BUILD và chỉ định các mục tiêu, hãy thêm các mục tiêu mới này vào thuộc tính deps của các mục tiêu phụ thuộc vào chúng.

  • Hàm glob() không vượt qua ranh giới gói, vì vậy, khi số lượng gói tăng lên, các tệp được so khớp bằng glob() sẽ thu hẹp.

  • Khi thêm tệp BUILD vào thư mục main, hãy thêm tệp BUILD vào thư mục test tương ứng.

  • Thực thi các giới hạn về mức độ hiển thị hợp lý trên các gói.

  • Tạo dự án sau mỗi thay đổi lớn đối với các tệp BUILD và sửa lỗi bản dựng khi bạn gặp lỗi.

Bước 5: Chạy bản dựng

Chạy bản dựng được di chuyển toàn bộ để đảm bảo bản dựng hoàn tất mà không có lỗi hoặc cảnh báo. Chạy từng ứng dụng và mục tiêu kiểm thử để dễ dàng tìm thấy nguồn của mọi lỗi xảy ra.

Ví dụ:

bazel build //:my-target

Bước 6: Tạo dự án Xcode bằng Tulsi

Khi tạo bản dựng bằng Bazel, các tệp WORKSPACEBUILD sẽ trở thành nguồn thông tin đáng tin cậy về bản dựng. Để Xcode nhận biết được điều này, bạn phải tạo một dự án Xcode tương thích với Bazel bằng Tulsi.

Khắc phục sự cố

Lỗi Bazel có thể xảy ra khi không đồng bộ với phiên bản Xcode đã chọn, chẳng hạn như khi bạn áp dụng bản cập nhật. Sau đây là một số điều bạn nên thử nếu đang gặp lỗi với Xcode, ví dụ: "Phải chỉ định phiên bản Xcode để sử dụng Apple CROSSTOOL".

  • Chạy Xcode theo cách thủ công và chấp nhận mọi điều khoản và điều kiện.

  • Sử dụng Xcode select để cho biết phiên bản chính xác, chấp nhận giấy phép và xoá trạng thái của Bazel.

  sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  sudo xcodebuild -license
  bazel sync --configure
  • Nếu cách này không hiệu quả, bạn cũng có thể thử chạy bazel clean --expunge.