Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Hệ thống xây dựng Soong

Trước khi phát hành Android 7.0, Android sử dụng GNU Make dành riêng để mô tả và thực hiện xây dựng quy tắc của nó. Hệ thống Make build được hỗ trợ và sử dụng rộng rãi, nhưng ở quy mô của Android đã trở nên chậm chạp, dễ xảy ra lỗi, không thể chỉnh sửa và khó kiểm tra. Các Soong xây dựng hệ thống cung cấp sự linh hoạt cần thiết cho Android được xây dựng.

Vì lý do này, các nhà phát triển nền tảng dự kiến ​​sẽ chuyển từ Make và áp dụng Soong càng sớm càng tốt. Gửi câu hỏi cho android-xây dựng Google Group để nhận được hỗ trợ.

Soong là gì?

Các Soong xây dựng hệ thống đã được giới thiệu trong Android 7.0 (Nougat) để thay thế Make. Nó thúc đẩy sự Kati GNU Công cụ thực hiện tạo bản sao và Ninja xây dựng hệ thống thành phần để tăng tốc độ xây dựng của Android.

Xem Make xây dựng hệ thống Android mô tả trong dự án mã nguồn mở Android (AOSP) cho chung hướng dẫnxây dựng hệ thống thay đổi cho Android.mk Nhà văn để tìm hiểu về những thay đổi cần thiết để thích ứng từ Make để Soong.

Xem các mục xây dựng liên quan đến trong phần chú giải cho các định nghĩa từ ngữ then chốt và các file tài liệu tham khảo Soong để biết chi tiết đầy đủ.

So sánh Make và Soong

Dưới đây là một so sánh về cấu hình Make với Soong hoàn thành như nhau trong một cấu hình Soong (Blueprint hoặc .bp ) tập tin.

Làm ví dụ

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux

LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src

LOCAL_SRC_FILES := $(call \
     all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)

Ví dụ về Soong

cc_library_shared {
     name: “libxmlrpc++”,

     rtti: true,
     cppflags: [
           “-Wall”,
           “-Werror”,
           “-fexceptions”,
     ],
     export_include_dirs: [“src”],
     srcs: [“src/**/*.cpp”],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

Xem cấu hình xây dựng đơn giản cho ví dụ cấu hình thử nghiệm cụ thể Soong.

Định dạng tệp Android.bp

Theo thiết kế, Android.bp file rất đơn giản. Chúng không chứa điều kiện hoặc câu lệnh luồng điều khiển; tất cả sự phức tạp được xử lý bằng logic xây dựng được viết bằng Go. Khi có thể, cú pháp và ngữ nghĩa của Android.bp file tương tự như file BUILD Bazel .

Mô-đun

Một mô-đun trong một Android.bp tập tin bắt đầu với một kiểu mô-đun tiếp theo là một tập hợp các thuộc tính trong name: "value", định dạng:

cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}

Mỗi mô-đun phải có một name tài sản, và giá trị phải là duy nhất trên tất cả các Android.bp tác phẩm, trừ các name giá trị tài sản trong không gian tên và các module được xây dựng sẵn, có thể lặp lại.

Các srcs quy định cụ thể sở hữu các tập tin nguồn dùng để xây dựng các mô-đun, như một danh sách các chuỗi. Bạn có thể tham khảo các sản phẩm của các module khác sản xuất các file nguồn, như genrule hoặc filegroup , bằng cách sử dụng cú pháp tham khảo mô-đun ":<module-name>" .

Đối với một danh sách các loại mô-đun hợp lệ và tài sản của họ, xem Soong Modules tham khảo .

Các loại

Các biến và thuộc tính được gõ mạnh, với các biến động dựa trên phép gán đầu tiên và các thuộc tính được đặt tĩnh theo kiểu mô-đun. Các loại được hỗ trợ là:

  • Boolean ( true hoặc false )
  • Số nguyên ( int )
  • Strings ( "string" )
  • Danh sách các chuỗi ( ["string1", "string2"] )
  • Maps ( {key1: "value1", key2: ["value2"]} )

Bản đồ có thể chứa các giá trị thuộc bất kỳ loại nào, bao gồm cả các bản đồ lồng nhau. Danh sách và bản đồ có thể có dấu phẩy ở cuối sau giá trị cuối cùng.

Globs

Thuộc tính mà phải mất một danh sách các tập tin, chẳng hạn như srcs , cũng có thể tận mẫu glob. Mẫu glob có thể chứa các ký tự đại diện bình thường UNIX * , ví dụ *.java . Mẫu glob cũng có thể chứa một đơn ** wildcard là một yếu tố con đường, mà phù hợp với zero hoặc nhiều yếu tố con đường. Ví dụ, java/**/*.java phù hợp với cả java/Main.javajava/com/android/Main.java mẫu.

Biến

Một Android.bp tập tin có thể chứa các bài tập biến cấp cao nhất:

gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
    name: "gzip",
    srcs: gzip_srcs,
    shared_libs: ["libz"],
    stl: "none",
}

Các biến được xác định phạm vi đến phần còn lại của tệp mà chúng được khai báo, cũng như bất kỳ tệp Bản thiết kế con nào. Biến là không thay đổi với một ngoại lệ: chúng có thể được gắn vào với một += chuyển nhượng, nhưng chỉ trước khi họ đã được tham chiếu.

Bình luận

Android.bp tập tin có thể chứa C-style multiline /* */ C ++ phong cách và dòng đơn // ý kiến.

Các nhà khai thác

Các chuỗi, danh sách các chuỗi và bản đồ có thể được thêm vào bằng cách sử dụng toán tử +. Số nguyên có thể được tóm tắt bằng cách sử dụng + nhà điều hành. Việc thêm một bản đồ tạo ra sự kết hợp của các khóa trong cả hai bản đồ, nối các giá trị của bất kỳ khóa nào có trong cả hai bản đồ.

Điều kiện

Soong không hỗ trợ điều kiện trong Android.bp tập tin. Thay vào đó, sự phức tạp trong các quy tắc xây dựng yêu cầu điều kiện được xử lý trong Go, nơi các tính năng ngôn ngữ cấp cao có thể được sử dụng và các phụ thuộc ngầm định được giới thiệu bởi các điều kiện có thể được theo dõi. Hầu hết các điều kiện được chuyển đổi thành thuộc tính bản đồ, trong đó một trong các giá trị trong bản đồ được chọn và nối vào thuộc tính cấp cao nhất.

Ví dụ: để hỗ trợ các tệp dành riêng cho kiến ​​trúc:

cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}

Định dạng

Soong bao gồm một định dạng kinh điển cho các tập tin Blueprint, tương tự như gofmt . Để đệ quy dạng lại tất cả Android.bp tập tin trong thư mục hiện hành, chạy:

bpfmt -w .

Định dạng chuẩn bao gồm 4 dấu cách thụt lề, các dòng mới sau mỗi phần tử của danh sách nhiều thành phần và dấu phẩy ở cuối trong danh sách và bản đồ.

Mô-đun đặc biệt

Một số nhóm mô-đun đặc biệt có các đặc điểm riêng biệt.

Mô-đun mặc định

Một mô-đun mặc định có thể được sử dụng để lặp lại các thuộc tính giống nhau trong nhiều mô-đun. Ví dụ:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

Các mô-đun dựng sẵn

Một số loại mô-đun dựng sẵn cho phép một mô-đun có cùng tên với các đối tác dựa trên nguồn của nó. Ví dụ, có thể là một cc_prebuilt_binary tên foo khi có đã là một cc_binary có cùng tên. Điều này cho phép các nhà phát triển linh hoạt trong việc lựa chọn phiên bản nào để đưa vào sản phẩm cuối cùng của họ. Nếu một cấu hình build chứa cả phiên bản, prefer giá trị cờ trong mệnh lệnh định nghĩa module dựng sẵn phiên bản nào có ưu tiên. Lưu ý rằng một số module được xây dựng sẵn có tên mà không bắt đầu với prebuilt , chẳng hạn như android_app_import .

Mô-đun không gian tên

Cho đến Android hoàn toàn chuyển đổi từ Make để Soong, cấu hình sản phẩm Make phải chỉ định một PRODUCT_SOONG_NAMESPACES giá trị. Giá trị của nó phải là một danh sách không gian tách biệt của không gian tên mà Soong xuất khẩu sang Make được xây dựng bởi các m lệnh. Sau khi quá trình chuyển đổi của Android thành Soong hoàn tất, các chi tiết về cách bật không gian tên có thể thay đổi.

Soong cung cấp khả năng cho các mô-đun trong các thư mục khác nhau chỉ định cùng một tên, miễn là mỗi mô-đun được khai báo trong một không gian tên riêng biệt. Một vùng tên có thể được khai báo như thế này:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

Lưu ý rằng không gian tên không có thuộc tính tên; đường dẫn của nó được tự động gán như tên của nó.

Mỗi mô-đun Soong được gán một không gian tên dựa trên vị trí của nó trong cây. Mỗi module Soong được coi là trong không gian tên được định nghĩa bởi soong_namespace tìm thấy trong một Android.bp tập tin trong thư mục hiện hành hoặc thư mục tổ tiên gần nhất. Nếu không như vậy soong_namespace mô-đun được tìm thấy, các mô-đun được coi là trong không gian tên gốc ngầm.

Đây là một ví dụ: Soong cố gắng giải quyết sự phụ thuộc D được khai báo bởi mô-đun M trong không gian tên N nhập các không gian tên I1, I2, I3…

  1. Sau đó, nếu D là một cái tên đầy đủ có dạng //namespace:module , chỉ có không gian tên cụ thể là tìm kiếm cho tên module quy định.
  2. Nếu không, trước tiên Soong tìm kiếm một mô-đun có tên D được khai báo trong không gian tên N.
  3. Nếu mô-đun đó không tồn tại, Soong sẽ tìm kiếm một mô-đun có tên D trong các không gian tên I1, I2, I3…
  4. Cuối cùng, Soong nhìn vào không gian tên gốc.