توفر هذه الصفحة عرضًا عالي المستوى لكيفية دعم المصدر الذي تم إنشاؤه وكيف يمكن استخدامه في نظام الإنشاء.
توفر جميع المولدات المصدرية وظائف نظام بناء مماثلة. تعمل حالات استخدام إنشاء المصدر الثلاثة المدعومة بنظام البناء على إنشاء روابط C باستخدام واجهات bindgen وAIDL وواجهات protobuf.
الصناديق من المصدر الذي تم إنشاؤه
يمكن استخدام كل وحدة Rust التي تولد كود المصدر كصندوق، تمامًا كما لو تم تعريفها على أنها rust_library . (وهذا يعني أنه يمكن تعريفها على أنها تبعية في خصائص rustlibs و rlibs و dylibs .) أفضل نمط استخدام لرمز النظام الأساسي هو استخدام المصدر المولد كصندوق. على الرغم من include! يتم دعم الماكرو للمصدر الذي تم إنشاؤه، والغرض الأساسي منه هو دعم كود الطرف الثالث الموجود في external/ .
هناك حالات قد يستمر فيها كود النظام الأساسي في استخدام المصدر الذي تم إنشاؤه من خلال include!() ، كما هو الحال عندما تستخدم وحدة genrule لإنشاء المصدر بطريقة فريدة.
استخدم include!() لتضمين المصدر الذي تم إنشاؤه
يتم تناول استخدام المصدر الذي تم إنشاؤه كصندوق من خلال الأمثلة الموجودة في كل صفحة وحدة محددة (معينة). يوضح هذا القسم كيفية الإشارة إلى المصدر الذي تم إنشاؤه من خلال include!() . لاحظ أن هذه العملية مشابهة لجميع المولدات المصدرية.
المتطلبات المسبقة
يستند هذا المثال إلى افتراض أنك قمت بتعريف وحدة rust_bindgen ( libbuzz_bindgen ) ويمكنك المتابعة إلى خطوات تضمين المصدر الذي تم إنشاؤه لاستخدام الماكرو include!() . إذا لم تقم بذلك، يرجى الانتقال إلى تعريف وحدة bindgen الصدئة ، وإنشاء libbuzz_bindgen ، ثم العودة هنا.
لاحظ أن أجزاء ملف البناء الخاصة بهذا تنطبق على جميع المولدات المصدرية.
خطوات تضمين المصدر الذي تم إنشاؤه
قم بإنشاء 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!("/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 مصدر التعبئة والتغليف في صندوق يمكن استيراده، لعدة أسباب:
- منع أسماء الملفات المصدر التي تم إنشاؤها من الاصطدام.
- تقليل تسجيل التعليمات البرمجية النمطية في جميع أنحاء الشجرة التي تتطلب الصيانة. يمكن صيانة أي نموذج معياري مطلوب لتجميع المصدر الذي تم إنشاؤه في صندوق مركزيًا.
- تجنب التفاعلات الضمنية بين التعليمات البرمجية التي تم إنشاؤها والصندوق المحيط.
- قم بتقليل الضغط على الذاكرة والقرص عن طريق ربط المصادر المولدة شائعة الاستخدام ديناميكيًا.
ونتيجة لذلك، تنتج جميع أنواع وحدات توليد مصدر Rust في Android تعليمات برمجية يمكن تجميعها واستخدامها كصندوق . لا يزال Soong يدعم صناديق الطرف الثالث دون تعديل إذا تم نسخ جميع تبعيات المصدر التي تم إنشاؤها لوحدة نمطية في دليل واحد لكل وحدة، على غرار Cargo. في مثل هذه الحالات، يقوم Soong بتعيين متغير البيئة OUT_DIR إلى هذا الدليل عند تجميع الوحدة، بحيث يمكن العثور على المصدر الذي تم إنشاؤه. ومع ذلك، للأسباب الموضحة بالفعل، فمن الأفضل استخدام هذه الآلية في كود النظام الأساسي فقط عندما يكون ذلك ضروريًا للغاية.
لا يمثل هذا أية مشكلات لـ C/C++ واللغات المشابهة، حيث يتم توفير المسار إلى المصدر الذي تم إنشاؤه مباشرة إلى المترجم. ↩
منذ
include!يعمل عن طريق التضمين النصي، فقد يشير إلى قيم من مساحة الاسم المتضمنة، أو يعدل مساحة الاسم، أو يستخدم بنيات مثل#![foo]. قد يكون من الصعب الحفاظ على هذه التفاعلات الضمنية. تفضل دائمًا وحدات الماكرو عندما يكون التفاعل مع بقية الصندوق مطلوبًا حقًا. ↩
توفر هذه الصفحة عرضًا عالي المستوى لكيفية دعم المصدر الذي تم إنشاؤه وكيف يمكن استخدامه في نظام الإنشاء.
توفر جميع المولدات المصدرية وظائف نظام بناء مماثلة. تعمل حالات استخدام إنشاء المصدر الثلاثة المدعومة بنظام البناء على إنشاء روابط C باستخدام واجهات bindgen وAIDL وواجهات protobuf.
الصناديق من المصدر الذي تم إنشاؤه
يمكن استخدام كل وحدة Rust التي تولد كود المصدر كصندوق، تمامًا كما لو تم تعريفها على أنها rust_library . (وهذا يعني أنه يمكن تعريفها على أنها تبعية في خصائص rustlibs و rlibs و dylibs .) أفضل نمط استخدام لرمز النظام الأساسي هو استخدام المصدر المولد كصندوق. على الرغم من include! يتم دعم الماكرو للمصدر الذي تم إنشاؤه، والغرض الأساسي منه هو دعم كود الطرف الثالث الموجود في external/ .
هناك حالات قد يستمر فيها كود النظام الأساسي في استخدام المصدر الذي تم إنشاؤه من خلال include!() ، كما هو الحال عندما تستخدم وحدة genrule لإنشاء المصدر بطريقة فريدة.
استخدم include!() لتضمين المصدر الذي تم إنشاؤه
يتم تناول استخدام المصدر الذي تم إنشاؤه كصندوق من خلال الأمثلة الموجودة في كل صفحة وحدة محددة (معينة). يوضح هذا القسم كيفية الإشارة إلى المصدر الذي تم إنشاؤه من خلال include!() . لاحظ أن هذه العملية مشابهة لجميع المولدات المصدرية.
المتطلبات المسبقة
يستند هذا المثال إلى افتراض أنك قمت بتعريف وحدة rust_bindgen ( libbuzz_bindgen ) ويمكنك المتابعة إلى خطوات تضمين المصدر الذي تم إنشاؤه لاستخدام الماكرو include!() . إذا لم تقم بذلك، يرجى الانتقال إلى تعريف وحدة bindgen الصدئة ، وإنشاء libbuzz_bindgen ، ثم العودة هنا.
لاحظ أن أجزاء ملف البناء الخاصة بهذا تنطبق على جميع المولدات المصدرية.
خطوات تضمين المصدر الذي تم إنشاؤه
قم بإنشاء 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!("/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 مصدر التعبئة والتغليف في صندوق يمكن استيراده، لعدة أسباب:
- منع أسماء الملفات المصدر التي تم إنشاؤها من الاصطدام.
- تقليل تسجيل التعليمات البرمجية النمطية في جميع أنحاء الشجرة التي تتطلب الصيانة. يمكن صيانة أي نموذج معياري مطلوب لتجميع المصدر الذي تم إنشاؤه في صندوق مركزيًا.
- تجنب التفاعلات الضمنية بين التعليمات البرمجية التي تم إنشاؤها والصندوق المحيط.
- قم بتقليل الضغط على الذاكرة والقرص عن طريق ربط المصادر المولدة شائعة الاستخدام ديناميكيًا.
ونتيجة لذلك، تنتج جميع أنواع وحدات توليد مصدر Rust في Android تعليمات برمجية يمكن تجميعها واستخدامها كصندوق . لا يزال Soong يدعم صناديق الطرف الثالث دون تعديل إذا تم نسخ جميع تبعيات المصدر التي تم إنشاؤها لوحدة نمطية في دليل واحد لكل وحدة، على غرار Cargo. في مثل هذه الحالات، يقوم Soong بتعيين متغير البيئة OUT_DIR إلى هذا الدليل عند تجميع الوحدة، بحيث يمكن العثور على المصدر الذي تم إنشاؤه. ومع ذلك، للأسباب الموضحة بالفعل، فمن الأفضل استخدام هذه الآلية في كود النظام الأساسي فقط عندما يكون ذلك ضروريًا للغاية.
لا يمثل هذا أية مشكلات لـ C/C++ واللغات المشابهة، حيث يتم توفير المسار إلى المصدر الذي تم إنشاؤه مباشرة إلى المترجم. ↩
منذ
include!يعمل عن طريق التضمين النصي، فقد يشير إلى قيم من مساحة الاسم المتضمنة، أو يعدل مساحة الاسم، أو يستخدم بنيات مثل#![foo]. قد يكون من الصعب الحفاظ على هذه التفاعلات الضمنية. تفضل دائمًا وحدات الماكرو عندما يكون التفاعل مع بقية الصندوق مطلوبًا حقًا. ↩
توفر هذه الصفحة عرضًا عالي المستوى لكيفية دعم المصدر الذي تم إنشاؤه وكيف يمكن استخدامه في نظام الإنشاء.
توفر جميع المولدات المصدرية وظائف نظام بناء مماثلة. تعمل حالات استخدام إنشاء المصدر الثلاثة المدعومة بنظام البناء على إنشاء روابط C باستخدام واجهات bindgen وAIDL وواجهات protobuf.
الصناديق من المصدر الذي تم إنشاؤه
يمكن استخدام كل وحدة Rust التي تولد كود المصدر كصندوق، تمامًا كما لو تم تعريفها على أنها rust_library . (وهذا يعني أنه يمكن تعريفها على أنها تبعية في خصائص rustlibs و rlibs و dylibs .) أفضل نمط استخدام لرمز النظام الأساسي هو استخدام المصدر المولد كصندوق. على الرغم من include! يتم دعم الماكرو للمصدر الذي تم إنشاؤه، والغرض الأساسي منه هو دعم كود الطرف الثالث الموجود في external/ .
هناك حالات قد يستمر فيها كود النظام الأساسي في استخدام المصدر الذي تم إنشاؤه من خلال include!() ، كما هو الحال عندما تستخدم وحدة genrule لإنشاء المصدر بطريقة فريدة.
استخدم include!() لتضمين المصدر الذي تم إنشاؤه
يتم تناول استخدام المصدر الذي تم إنشاؤه كصندوق من خلال الأمثلة الموجودة في كل صفحة وحدة محددة (معينة). يوضح هذا القسم كيفية الإشارة إلى المصدر الذي تم إنشاؤه من خلال include!() . لاحظ أن هذه العملية مشابهة لجميع المولدات المصدرية.
المتطلبات المسبقة
يستند هذا المثال إلى افتراض أنك قمت بتعريف وحدة rust_bindgen ( libbuzz_bindgen ) ويمكنك المتابعة إلى خطوات تضمين المصدر الذي تم إنشاؤه لاستخدام الماكرو include!() . إذا لم تقم بذلك، يرجى الانتقال إلى تعريف وحدة bindgen الصدئة ، وإنشاء libbuzz_bindgen ، ثم العودة هنا.
لاحظ أن أجزاء ملف البناء الخاصة بهذا تنطبق على جميع المولدات المصدرية.
خطوات تضمين المصدر الذي تم إنشاؤه
قم بإنشاء 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!("/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 مصدر التعبئة والتغليف في صندوق يمكن استيراده، لعدة أسباب:
- منع أسماء الملفات المصدر التي تم إنشاؤها من الاصطدام.
- تقليل تسجيل التعليمات البرمجية النمطية في جميع أنحاء الشجرة التي تتطلب الصيانة. يمكن صيانة أي نموذج معياري مطلوب لتجميع المصدر الذي تم إنشاؤه في صندوق مركزيًا.
- تجنب التفاعلات الضمنية بين التعليمات البرمجية التي تم إنشاؤها والصندوق المحيط.
- قم بتقليل الضغط على الذاكرة والقرص عن طريق ربط المصادر المولدة شائعة الاستخدام ديناميكيًا.
ونتيجة لذلك، تنتج جميع أنواع وحدات إنشاء مصدر Rust في Android تعليمات برمجية يمكن تجميعها واستخدامها كصندوق . لا يزال Soong يدعم صناديق الطرف الثالث دون تعديل إذا تم نسخ جميع تبعيات المصدر التي تم إنشاؤها لوحدة نمطية في دليل واحد لكل وحدة، على غرار Cargo. في مثل هذه الحالات، يقوم Soong بتعيين متغير البيئة OUT_DIR إلى هذا الدليل عند تجميع الوحدة، بحيث يمكن العثور على المصدر الذي تم إنشاؤه. ومع ذلك، للأسباب الموضحة بالفعل، فمن الأفضل استخدام هذه الآلية في كود النظام الأساسي فقط عندما يكون ذلك ضروريًا للغاية.
لا يمثل هذا أية مشكلات لـ C/C++ واللغات المشابهة، حيث يتم توفير المسار إلى المصدر الذي تم إنشاؤه مباشرة إلى المترجم. ↩
منذ
include!يعمل عن طريق التضمين النصي، فقد يشير إلى قيم من مساحة الاسم المتضمنة، أو يعدل مساحة الاسم، أو يستخدم بنيات مثل#![foo]. قد يكون من الصعب الحفاظ على هذه التفاعلات الضمنية. تفضل دائمًا وحدات الماكرو عندما يكون التفاعل مع بقية الصندوق مطلوبًا حقًا. ↩