Theo nguyên tắc chung, các định nghĩa mô-đun rust_*
tuân thủ chặt chẽ việc sử dụng và mong đợi cc_*
. Sau đây là ví dụ về định nghĩa mô-đun cho tệp nhị phân Rust :
rust_binary {
name: "hello_rust",
crate_name: "hello_rust",
srcs: ["src/hello_rust.rs"],
host_supported: true,
}
Trang này bao gồm các thuộc tính phổ biến nhất cho mô-đun rust_*
. Để biết thêm thông tin về các loại mô-đun cụ thể và định nghĩa mô-đun mẫu, hãy xem Mô-đun nhị phân , Mô-đun thư viện hoặc Mô-đun thử nghiệm .
Các loại mô-đun cơ bản
Kiểu | Sự định nghĩa | Để biết thêm thông tin |
---|---|---|
rust_binary | Một hệ nhị phân Rust | Trang mô-đun nhị phân |
rust_library | Tạo thư viện Rust và cung cấp cả biến thể rlib và dylib . | rust_library , trang Mô-đun thư viện. |
rust_ffi | Tạo thư viện Rust C mà các mô-đun cc có thể sử dụng được và cung cấp cả biến thể tĩnh và biến thể dùng chung. | rust_ffi , trang Mô-đun thư viện |
rust_proc_macro | Tạo thư viện proc-macro Rust . (Đây là những plugin tương tự như trình biên dịch.) | rust_proc_macro , trang Mô-đun thư viện |
rust_test | Tạo tệp nhị phân thử nghiệm Rust sử dụng khai thác thử nghiệm Rust tiêu chuẩn. | Trang mô-đun thử nghiệm |
rust_fuzz | Tạo ra một libfuzzer tận dụng nhị phân Rust fuzz . | ví dụ về mô-đun rust_fuzz |
rust_protobuf | Tạo nguồn và tạo thư viện Rust cung cấp giao diện cho một protobuf cụ thể. | Các trang Mô-đun Protobufs và Trình tạo nguồn |
rust_bindgen | Tạo nguồn và tạo thư viện Rust chứa các liên kết Rust với thư viện C. | Các trang Mô-đun ràng buộc Bindgen và Trình tạo nguồn |
Thuộc tính chung quan trọng
Các thuộc tính này phổ biến trên tất cả các Mô-đun Android Rust . Bất kỳ thuộc tính bổ sung (duy nhất) nào được liên kết với các mô-đun Rust riêng lẻ đều được liệt kê trên trang của mô-đun đó.
tên
name
là tên mô-đun của bạn. Giống như các mô-đun Soong khác, mô-đun này phải là duy nhất trên hầu hết các loại mô-đun Android.bp
. Theo mặc định, name
được sử dụng làm tên tệp đầu ra. Nếu tên tệp đầu ra phải khác với tên mô-đun, hãy sử dụng thuộc tính stem
để xác định nó.
thân cây
stem
(tùy chọn) cung cấp quyền kiểm soát trực tiếp tên tệp đầu ra (không bao gồm phần mở rộng tệp và các hậu tố khác). Ví dụ: thư viện rust_library_rlib
có giá trị gốc là libfoo
sẽ tạo ra tệp libfoo.rlib
. Nếu bạn không cung cấp giá trị cho thuộc tính stem
, tên tệp đầu ra sẽ lấy tên mô-đun theo mặc định.
Sử dụng hàm stem
khi bạn không thể đặt tên mô-đun thành tên tệp đầu ra mong muốn. Ví dụ: rust_library
cho thùng log
được đặt tên là liblog_rust
, vì liblog cc_library
đã tồn tại. Việc sử dụng thuộc tính stem
trong trường hợp này đảm bảo rằng tệp đầu ra được đặt tên là liblog.*
thay vì liblog_rust.*
.
src
srcs
chứa một tệp nguồn duy nhất đại diện cho điểm vào mô-đun của bạn (thường là main.rs
hoặc lib.rs
). rustc
xử lý việc phân giải và khám phá tất cả các tệp nguồn khác cần thiết để biên dịch và chúng được liệt kê trong tệp deps
được tạo.
Khi có thể, hãy tránh cách sử dụng mã nền tảng này; xem Trình tạo nguồn để biết thêm thông tin.
tên thùng
crate_name
đặt siêu dữ liệu tên thùng thông qua cờ rustc
--crate_name
. Đối với các mô-đun tạo thư viện, tên này phải khớp với tên thùng dự kiến được sử dụng trong nguồn. Ví dụ: nếu mô-đun libfoo_bar
được tham chiếu trong nguồn dưới dạng extern crate foo_bar
thì đây phải là thùng_name: "foo_bar".
Thuộc tính này chung cho tất cả các mô-đun rust_*
, nhưng nó bắt buộc đối với các mô-đun tạo thư viện Rust (chẳng hạn như rust_library
rust_ffi
, rust_bindgen
, rust_protobuf
và rust_proc_macro
). Các mô-đun này thực thi rustc
yêu cầu về mối quan hệ giữa crate_name
và tên tệp đầu ra. Để biết thêm thông tin, hãy xem phần Mô-đun thư viện .
xơ vải
Rustc linter được chạy theo mặc định cho tất cả các loại mô-đun ngoại trừ trình tạo nguồn. Một số nhóm tìm lỗi mã nguồn được xác định và sử dụng để xác thực nguồn mô-đun. Các giá trị có thể có cho các tập hợp lint như sau:
-
default
tập hợp các lint mặc định, tùy thuộc vào vị trí của mô-đun -
android
bộ tìm lỗi mã nguồn nghiêm ngặt nhất áp dụng cho tất cả mã nền tảng Android -
vendor
một bộ lint thoải mái được áp dụng cho mã nhà cung cấp -
none
để bỏ qua tất cả các cảnh báo và lỗi tìm lỗi mã nguồn
clippy_lint
Kẻ nói dối clippy cũng được chạy theo mặc định cho tất cả các loại mô-đun ngoại trừ trình tạo nguồn. Một số tập hợp lint được xác định được sử dụng để xác thực nguồn mô-đun. Đây là một số giá trị có thể:
- tập hợp các lint mặc
default
tùy thuộc vào vị trí của mô-đun -
android
bộ tìm lỗi mã nguồn nghiêm ngặt nhất áp dụng cho tất cả mã nền tảng Android -
vendor
một bộ lint thoải mái được áp dụng cho mã nhà cung cấp -
none
để bỏ qua tất cả các cảnh báo và lỗi tìm lỗi mã nguồn
phiên bản
edition
xác định phiên bản Rust sẽ được sử dụng để biên dịch mã này. Điều này tương tự như phiên bản std cho C và C++. Giá trị hợp lệ là 2015
và 2018
(mặc định).
cờ
flags
chứa danh sách chuỗi các cờ để chuyển tới rustc
trong quá trình biên dịch.
ld_flags
ld-flags
chứa danh sách chuỗi các cờ để chuyển tới trình liên kết khi biên dịch nguồn. Chúng được chuyển qua cờ -C linker-args
Rustc. clang
được sử dụng làm giao diện người dùng của trình liên kết, gọi lld
để liên kết thực tế.
đặc trưng
features
là danh sách chuỗi các tính năng phải được bật trong quá trình biên dịch. Điều này được chuyển tới Rustc bởi --cfg 'feature="foo"'
. Hầu hết các tính năng đều mang tính bổ sung, vì vậy trong nhiều trường hợp, tính năng này bao gồm bộ tính năng đầy đủ được yêu cầu bởi tất cả các mô-đun phụ thuộc. Tuy nhiên, trong trường hợp các tính năng độc quyền với nhau, hãy xác định các mô-đun bổ sung trong bất kỳ tệp xây dựng nào cung cấp các tính năng xung đột.
cfg
cfgs
chứa danh sách chuỗi các cờ cfg
sẽ được bật trong quá trình biên dịch. Điều này được chuyển tới rustc
bởi --cfg foo
và --cfg "fizz=buzz"
.
Hệ thống xây dựng tự động đặt một số cờ cfg
nhất định trong các tình huống cụ thể, được liệt kê bên dưới:
Các mô-đun được xây dựng dưới dạng dylib sẽ có tập hợp
android_dylib
cfg.Các module sử dụng VNDK sẽ có tập hợp
android_vndk
cfg. Điều này tương tự như định nghĩa__ANDROID_VNDK__
cho C++.
dải
strip
kiểm soát xem tệp đầu ra có bị loại bỏ hay không (nếu có). Nếu bạn không đặt tùy chọn này, thì các mô-đun thiết bị sẽ theo mặc định loại bỏ mọi thứ ngoại trừ thông tin gỡ lỗi nhỏ. Theo mặc định, các mô-đun máy chủ không loại bỏ bất kỳ ký hiệu nào. Các giá trị hợp lệ none
bao gồm giá trị nào để vô hiệu hóa tính năng tước và all
để loại bỏ mọi thứ, bao gồm cả thông tin gỡ lỗi nhỏ. Các giá trị bổ sung có thể được tìm thấy trong Tài liệu tham khảo mô-đun Soong .
máy chủ_được hỗ trợ
Đối với mô-đun thiết bị, tham số host_supported
cho biết liệu mô-đun đó có nên cung cấp biến thể máy chủ hay không.
Xác định phụ thuộc thư viện
Các mô-đun Rust có thể phụ thuộc vào cả thư viện CC và Rust thông qua các thuộc tính sau:
Tên tài sản | Sự miêu tả |
---|---|
rustlibs | Danh sách các mô-đun rust_library cũng là các mô-đun phụ thuộc. Hãy sử dụng phương pháp này làm phương pháp khai báo các phần phụ thuộc ưa thích của bạn vì nó cho phép hệ thống xây dựng chọn liên kết ưu tiên. (Xem Khi liên kết với thư viện Rust bên dưới) |
rlibs | Danh sách các mô-đun rust_library phải được liên kết tĩnh dưới dạng rlibs . (Hãy thận trọng khi sử dụng; xem Khi liên kết với thư viện Rust bên dưới.) |
shared_libs | Danh sách các mô-đun cc_library phải được liên kết động dưới dạng thư viện dùng chung. |
static_libs | Danh sách các mô-đun cc_library phải được liên kết tĩnh dưới dạng thư viện tĩnh. |
whole_static_libs | Danh sách các mô-đun cc_library cần được liên kết tĩnh dưới dạng thư viện tĩnh và được bao gồm toàn bộ trong thư viện kết quả. Đối với các biến thể rust_ffi_static , whole_static_libraries sẽ được đưa vào kho lưu trữ thư viện tĩnh thu được. Đối với các biến thể rust_library_rlib , thư viện whole_static_libraries sẽ được gộp vào thư viện rlib thu được. |
Khi liên kết với các thư viện Rust , cách tốt nhất là sử dụng thuộc tính rustlibs
thay vì rlibs
hoặc dylibs
trừ khi bạn có lý do cụ thể để làm như vậy. Điều này cho phép hệ thống xây dựng chọn liên kết chính xác dựa trên những gì mô-đun gốc yêu cầu và nó làm giảm khả năng cây phụ thuộc chứa cả phiên bản rlib
và dylib
của thư viện (điều này sẽ khiến quá trình biên dịch không thành công).
Các tính năng xây dựng hỗ trợ không được hỗ trợ và hạn chế
Rust của Soong cung cấp hỗ trợ hạn chế cho các hình ảnh và ảnh chụp nhanh vendor
và vendor_ramdisk
. Tuy nhiên, staticlibs
, cdylibs
, rlibs
và binaries
được hỗ trợ. Đối với mục tiêu xây dựng hình ảnh nhà cung cấp, thuộc tính android_vndk
cfg
được đặt. Bạn có thể sử dụng mã này trong mã nếu có sự khác biệt giữa mục tiêu của hệ thống và nhà cung cấp. rust_proc_macros
không được ghi lại như một phần của ảnh chụp nhanh của nhà cung cấp; nếu những điều này phụ thuộc vào, hãy đảm bảo bạn kiểm soát phiên bản chúng một cách thích hợp.
Hình ảnh sản phẩm, VNDK và Recovery không được hỗ trợ.
Bản dựng tăng dần
Các nhà phát triển có thể kích hoạt quá trình biên dịch gia tăng nguồn Rust bằng cách đặt biến môi trường SOONG_RUSTC_INCREMENTAL
thành true
.
Cảnh báo : Điều này không đảm bảo tạo ra các tệp nhị phân giống hệt với các tệp được tạo bởi buildbots. Địa chỉ của các hàm hoặc dữ liệu chứa trong tệp đối tượng có thể khác nhau. Để đảm bảo rằng các tạo phẩm được tạo giống 100% với các tạo phẩm được xây dựng bởi cơ sở hạ tầng EngProd, hãy không đặt giá trị này.