מחוללי מקור

דף זה מספק תצוגה ברמה גבוהה של האופן שבו המקור שנוצר נתמך וכיצד ניתן להשתמש בו במערכת הבנייה.

כל מחוללי המקור מספקים פונקציונליות מערכת בנייה דומה. שלושת מקרי השימוש הנתמכים ב-build-system הם יצירת כריכות C באמצעות bindgen, ממשקי AIDL וממשקי protobuf.

ארגזים ממקור שנוצר

כל מודול Rust שיוצר קוד מקור יכול לשמש כארגז, בדיוק כאילו הוא היה מוגדר כ- rust_library . (משמעות הדבר היא שניתן להגדיר אותה כתלות במאפייני rustlibs , rlibs ו- dylibs .) דפוס השימוש הטוב ביותר עבור קוד פלטפורמה הוא להשתמש במקור שנוצר בתור ארגז. למרות include! מאקרו נתמך עבור מקור שנוצר, המטרה העיקרית שלו היא לתמוך בקוד של צד שלישי שנמצא ב- external/ .

ישנם מקרים שבהם קוד הפלטפורמה עדיין עשוי להשתמש במקור שנוצר באמצעות המאקרו include!() , כגון כאשר אתה משתמש במודול genrule כדי ליצור מקור בצורה ייחודית.

השתמש ב- include!() כדי לכלול מקור שנוצר

השימוש במקור שנוצר בתור ארגז מכוסה על ידי הדוגמאות בכל עמוד מודול ספציפי (בהתאמה). סעיף זה מראה כיצד להפנות למקור שנוצר באמצעות המאקרו include!() . שימו לב שתהליך זה דומה עבור כל מחוללי המקור.

תְנַאִי מוּקדָם

דוגמה זו מבוססת על ההנחה שהגדרת מודול rust_bindgen ( libbuzz_bindgen ) ואתה יכול להמשיך לשלבים עבור הכללת מקור שנוצר לשימוש במאקרו include!() . אם לא עשית זאת, אנא עבור אל הגדרת מודול חלודה bindinggen , צור libbuzz_bindgen , ולאחר מכן חזור לכאן.

שים לב שהחלקים של קובץ ה-build של זה חלים על כל מחוללי המקור.

שלבים להכללת מקור שנוצר

צור external/rust/hello_bindgen/Android.bp עם התכנים הבאים:

rust_binary {
   name: "hello_bzip_bindgen_include",
   srcs: [
         // The primary rust source file must come first in this list.
         "src/lib.rs",

         // The module providing the bindgen bindings is
         // included in srcs prepended by ":".
         ":libbuzz_bindgen",
    ],

    // Dependencies need to be redeclared when generated source is used via srcs.
    shared_libs: [
        "libbuzz",
    ],
}

צור external/rust/hello_bindgen/src/bindings.rs עם התוכן הבא:

#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]

// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));

צור external/rust/hello_bindgen/src/lib.rs עם התוכן הבא:

mod bindings;

fn main() {
    let mut x = bindings::foo { x: 2 };
    unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}

למה ארגזים למקור שנוצר

שלא כמו מהדרים של C/C++, rustc מקבל רק קובץ מקור בודד המייצג נקודת כניסה לבינארי או ספרייה. הוא מצפה שעץ המקור יהיה בנוי כך שניתן יהיה לגלות אוטומטית את כל קבצי המקור הנדרשים. משמעות הדבר היא שמקור שנוצר חייב להיות ממוקם בעץ המקור, או לספק באמצעות הוראת include במקור:

include!("/path/to/hello.rs");

קהילת Rust תלויה בסקריפטים build.rs , ובהנחות לגבי סביבת הבנייה של Cargo, כדי לעבוד עם ההבדל הזה . כאשר היא בונה, הפקודה cargo מגדירה משתנה סביבתי OUT_DIR שלתוכו צפויים סקריפטים build.rs למקם קוד מקור שנוצר. השתמש בפקודה הבאה כדי לכלול קוד מקור:

include!(concat!(env!("OUT_DIR"), "/hello.rs"));

זה מהווה אתגר עבור Soong מכיוון שהפלטים עבור כל מודול ממוקמים בספריית ה- out/ שלהם 1 . אין OUT_DIR אחד שבו התלות מפלטת את המקור שנוצר שלהם.

עבור קוד פלטפורמה, AOSP מעדיף מקור שנוצר באריזה לתוך ארגז שניתן לייבא, מכמה סיבות:

  • מנע משמות קבצי מקור שנוצרו להתנגש.
  • צמצם את קוד ה-boilerplate שצ'ק-אין בכל העץ הדורש תחזוקה. ניתן לתחזק באופן מרכזי כל לוח שנדרש כדי להפוך את המקור שנוצר לארגז.
  • הימנע מ -2 אינטראקציות מרומזות בין הקוד שנוצר לבין הארגז שמסביב.
  • הפחת את הלחץ על הזיכרון והדיסק על ידי קישור דינמי של מקורות שנוצרו בשימוש נפוץ.

כתוצאה מכך, כל סוגי המודולים ליצירת מקור Rust של אנדרואיד מייצרים קוד שניתן להידור ולהשתמש בו בתור ארגז . Soong עדיין תומך בארגזים של צד שלישי ללא שינוי אם כל תלות המקור שנוצרת עבור מודול מועתקות לספרייה אחת לכל מודול, בדומה ל-Cargo. במקרים כאלה, Soong מגדיר את משתנה הסביבה OUT_DIR לספרייה זו בעת הידור המודול, כך שניתן יהיה למצוא את המקור שנוצר. עם זאת, מהסיבות שתוארו כבר, עדיף להשתמש במנגנון זה בקוד הפלטפורמה רק כאשר זה הכרחי לחלוטין.


  1. זה לא מציג בעיות עבור C/C++ ושפות דומות, מכיוון שהנתיב למקור שנוצר מסופק ישירות לקומפיילר.

  2. מאז include! עובד על ידי הכללה טקסטואלית, הוא עשוי להפנות לערכים ממרחב השמות המקיף, לשנות את מרחב השמות או להשתמש במבנים כמו #![foo] . אינטראקציות מרומזות אלו יכולות להיות קשות לתחזוקה. העדיפו תמיד פקודות מאקרו כאשר באמת נדרשת אינטראקציה עם שאר הארגז.

,

דף זה מספק תצוגה ברמה גבוהה של האופן שבו המקור שנוצר נתמך וכיצד ניתן להשתמש בו במערכת הבנייה.

כל מחוללי המקור מספקים פונקציונליות מערכת בנייה דומה. שלושת מקרי השימוש הנתמכים ב-build-system הם יצירת כריכות C באמצעות bindgen, ממשקי AIDL וממשקי protobuf.

ארגזים ממקור שנוצר

כל מודול Rust שיוצר קוד מקור יכול לשמש כארגז, בדיוק כאילו הוא היה מוגדר כ- rust_library . (משמעות הדבר היא שניתן להגדיר אותה כתלות במאפייני rustlibs , rlibs ו- dylibs .) דפוס השימוש הטוב ביותר עבור קוד פלטפורמה הוא להשתמש במקור שנוצר בתור ארגז. למרות include! מאקרו נתמך עבור מקור שנוצר, המטרה העיקרית שלו היא לתמוך בקוד של צד שלישי שנמצא ב- external/ .

ישנם מקרים שבהם קוד הפלטפורמה עדיין עשוי להשתמש במקור שנוצר דרך include!() , כגון כאשר אתה משתמש במודול genrule כדי ליצור מקור בצורה ייחודית.

השתמש ב- include!() כדי לכלול מקור שנוצר

השימוש במקור שנוצר בתור ארגז מכוסה על ידי הדוגמאות בכל עמוד מודול ספציפי (בהתאמה). סעיף זה מראה כיצד להפנות למקור שנוצר באמצעות המאקרו include!() . שימו לב שתהליך זה דומה עבור כל מחוללי המקור.

תְנַאִי מוּקדָם

דוגמה זו מבוססת על ההנחה שהגדרת מודול rust_bindgen ( libbuzz_bindgen ) ואתה יכול להמשיך לשלבים להכללת מקור שנוצר לשימוש במאקרו include!() . אם לא עשית זאת, אנא עבור אל הגדרת מודול חלודה bindinggen , צור libbuzz_bindgen , ולאחר מכן חזור לכאן.

שים לב שהחלקים של קובץ ה-build של זה חלים על כל מחוללי המקור.

שלבים להכללת מקור שנוצר

צור external/rust/hello_bindgen/Android.bp עם התכנים הבאים:

rust_binary {
   name: "hello_bzip_bindgen_include",
   srcs: [
         // The primary rust source file must come first in this list.
         "src/lib.rs",

         // The module providing the bindgen bindings is
         // included in srcs prepended by ":".
         ":libbuzz_bindgen",
    ],

    // Dependencies need to be redeclared when generated source is used via srcs.
    shared_libs: [
        "libbuzz",
    ],
}

צור external/rust/hello_bindgen/src/bindings.rs עם התוכן הבא:

#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]

// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));

צור external/rust/hello_bindgen/src/lib.rs עם התוכן הבא:

mod bindings;

fn main() {
    let mut x = bindings::foo { x: 2 };
    unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}

למה ארגזים למקור שנוצר

שלא כמו מהדרים של C/C++, rustc מקבל רק קובץ מקור בודד המייצג נקודת כניסה לבינארי או ספרייה. הוא מצפה שעץ המקור יהיה בנוי כך שניתן יהיה לגלות אוטומטית את כל קבצי המקור הנדרשים. משמעות הדבר היא שמקור שנוצר חייב להיות ממוקם בעץ המקור, או לספק באמצעות הוראת include במקור:

include!("/path/to/hello.rs");

קהילת Rust תלויה בסקריפטים build.rs , ובהנחות לגבי סביבת הבנייה של Cargo, כדי לעבוד עם ההבדל הזה . כאשר היא בונה, הפקודה cargo מגדירה משתנה סביבתי OUT_DIR שלתוכו צפויים סקריפטים build.rs למקם קוד מקור שנוצר. השתמש בפקודה הבאה כדי לכלול קוד מקור:

include!(concat!(env!("OUT_DIR"), "/hello.rs"));

זה מהווה אתגר עבור Soong מכיוון שהפלטים עבור כל מודול ממוקמים בספריית ה- out/ שלהם 1 . אין OUT_DIR אחד שבו התלות מפלטת את המקור שנוצר שלהם.

עבור קוד פלטפורמה, AOSP מעדיף מקור שנוצר באריזה לתוך ארגז שניתן לייבא, מכמה סיבות:

  • מנע משמות קבצי מקור שנוצרו להתנגש.
  • צמצם את קוד ה-boilerplate שצ'ק-אין בכל העץ הדורש תחזוקה. ניתן לתחזק באופן מרכזי כל לוח שנדרש כדי להפוך את המקור שנוצר לארגז.
  • הימנע מ -2 אינטראקציות מרומזות בין הקוד שנוצר לבין הארגז שמסביב.
  • הפחת את הלחץ על הזיכרון והדיסק על ידי קישור דינמי של מקורות שנוצרו בשימוש נפוץ.

כתוצאה מכך, כל סוגי המודולים ליצירת מקור Rust של אנדרואיד מייצרים קוד שניתן להידור ולהשתמש בו בתור ארגז . Soong עדיין תומך בארגזים של צד שלישי ללא שינוי אם כל תלות המקור שנוצרת עבור מודול מועתקות לספרייה אחת לכל מודול, בדומה ל-Cargo. במקרים כאלה, Soong מגדיר את משתנה הסביבה OUT_DIR לספרייה זו בעת הידור המודול, כך שניתן יהיה למצוא את המקור שנוצר. עם זאת, מהסיבות שתוארו כבר, עדיף להשתמש במנגנון זה בקוד הפלטפורמה רק כאשר זה הכרחי לחלוטין.


  1. זה לא מציג בעיות עבור C/C++ ושפות דומות, מכיוון שהנתיב למקור שנוצר מסופק ישירות לקומפיילר.

  2. מאז include! עובד על ידי הכללה טקסטואלית, הוא עשוי להפנות לערכים ממרחב השמות המקיף, לשנות את מרחב השמות או להשתמש במבנים כמו #![foo] . אינטראקציות מרומזות אלו יכולות להיות קשות לתחזוקה. העדיפו תמיד פקודות מאקרו כאשר באמת נדרשת אינטראקציה עם שאר הארגז.

,

דף זה מספק תצוגה ברמה גבוהה של האופן שבו המקור שנוצר נתמך וכיצד ניתן להשתמש בו במערכת הבנייה.

כל מחוללי המקור מספקים פונקציונליות מערכת בנייה דומה. שלושת מקרי השימוש הנתמכים ב-build-system הם יצירת כריכות C באמצעות bindgen, ממשקי AIDL וממשקי protobuf.

ארגזים ממקור שנוצר

כל מודול Rust שיוצר קוד מקור יכול לשמש כארגז, בדיוק כאילו הוא היה מוגדר כ- rust_library . (משמעות הדבר היא שניתן להגדיר אותה כתלות במאפייני rustlibs , rlibs ו- dylibs .) דפוס השימוש הטוב ביותר עבור קוד פלטפורמה הוא להשתמש במקור שנוצר בתור ארגז. למרות include! מאקרו נתמך עבור מקור שנוצר, המטרה העיקרית שלו היא לתמוך בקוד של צד שלישי שנמצא ב- external/ .

ישנם מקרים שבהם קוד הפלטפורמה עדיין עשוי להשתמש במקור שנוצר דרך include!() , כגון כאשר אתה משתמש במודול genrule כדי ליצור מקור בצורה ייחודית.

השתמש ב- include!() כדי לכלול מקור שנוצר

השימוש במקור שנוצר בתור ארגז מכוסה על ידי הדוגמאות בכל עמוד מודול ספציפי (בהתאמה). סעיף זה מראה כיצד להפנות למקור שנוצר באמצעות המאקרו include!() . שימו לב שתהליך זה דומה עבור כל מחוללי המקור.

תְנַאִי מוּקדָם

דוגמה זו מבוססת על ההנחה שהגדרת מודול rust_bindgen ( libbuzz_bindgen ) ואתה יכול להמשיך לשלבים עבור הכללת מקור שנוצר לשימוש במאקרו include!() . אם לא עשית זאת, אנא עבור אל הגדרת מודול חלודה bindinggen , צור libbuzz_bindgen , ולאחר מכן חזור לכאן.

שים לב שהחלקים של קובץ ה-build של זה חלים על כל מחוללי המקור.

שלבים להכללת מקור שנוצר

צור external/rust/hello_bindgen/Android.bp עם התכנים הבאים:

rust_binary {
   name: "hello_bzip_bindgen_include",
   srcs: [
         // The primary rust source file must come first in this list.
         "src/lib.rs",

         // The module providing the bindgen bindings is
         // included in srcs prepended by ":".
         ":libbuzz_bindgen",
    ],

    // Dependencies need to be redeclared when generated source is used via srcs.
    shared_libs: [
        "libbuzz",
    ],
}

צור external/rust/hello_bindgen/src/bindings.rs עם התוכן הבא:

#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]

// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));

צור external/rust/hello_bindgen/src/lib.rs עם התוכן הבא:

mod bindings;

fn main() {
    let mut x = bindings::foo { x: 2 };
    unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}

למה ארגזים למקור שנוצר

שלא כמו מהדרים של C/C++, rustc מקבל רק קובץ מקור בודד המייצג נקודת כניסה לבינארי או ספרייה. הוא מצפה שעץ המקור יהיה בנוי כך שניתן יהיה לגלות אוטומטית את כל קבצי המקור הנדרשים. משמעות הדבר היא שמקור שנוצר חייב להיות ממוקם בעץ המקור, או לספק באמצעות הוראת include במקור:

include!("/path/to/hello.rs");

קהילת Rust תלויה בסקריפטים build.rs , ובהנחות לגבי סביבת הבנייה של Cargo, כדי לעבוד עם ההבדל הזה . כאשר היא בונה, הפקודה cargo מגדירה משתנה סביבתי OUT_DIR שלתוכו צפויים סקריפטים build.rs למקם קוד מקור שנוצר. השתמש בפקודה הבאה כדי לכלול קוד מקור:

include!(concat!(env!("OUT_DIR"), "/hello.rs"));

זה מהווה אתגר עבור Soong מכיוון שהפלטים עבור כל מודול ממוקמים בספריית ה- out/ שלהם 1 . אין OUT_DIR אחד שבו התלות מפלטת את המקור שנוצר שלהם.

עבור קוד פלטפורמה, AOSP מעדיף מקור שנוצר באריזה לתוך ארגז שניתן לייבא, מכמה סיבות:

  • מנע משמות קבצי מקור שנוצרו להתנגש.
  • צמצם את קוד ה-boilerplate שצ'ק-אין בכל העץ הדורש תחזוקה. ניתן לתחזק באופן מרכזי כל לוח שנדרש כדי להפוך את המקור שנוצר לארגז.
  • הימנע מ -2 אינטראקציות מרומזות בין הקוד שנוצר לבין הארגז שמסביב.
  • הפחת את הלחץ על הזיכרון והדיסק על ידי קישור דינמי של מקורות שנוצרו בשימוש נפוץ.

כתוצאה מכך, כל סוגי המודולים ליצירת מקור Rust של אנדרואיד מייצרים קוד שניתן להידור ולהשתמש בו בתור ארגז . Soong עדיין תומך בארגזים של צד שלישי ללא שינוי אם כל תלות המקור שנוצרת עבור מודול מועתקות לספרייה אחת לכל מודול, בדומה ל-Cargo. במקרים כאלה, Soong מגדיר את משתנה הסביבה OUT_DIR לספרייה זו בעת הידור המודול, כך שניתן יהיה למצוא את המקור שנוצר. עם זאת, מהסיבות שתוארו כבר, עדיף להשתמש במנגנון זה בקוד הפלטפורמה רק כאשר זה הכרחי לחלוטין.


  1. זה לא מציג בעיות עבור C/C++ ושפות דומות, מכיוון שהנתיב למקור שנוצר מסופק ישירות לקומפיילר.

  2. מאז include! עובד על ידי הכללה טקסטואלית, הוא עשוי להפנות לערכים ממרחב השמות המקיף, לשנות את מרחב השמות או להשתמש במבנים כמו #![foo] . אינטראקציות מרומזות אלו יכולות להיות קשות לתחזוקה. העדיפו תמיד פקודות מאקרו כאשר באמת נדרשת אינטראקציה עם שאר הארגז.