Generadores de fuentes

Esta página proporciona una vista de alto nivel de cómo se admite el código fuente generado y cómo se puede utilizar en el sistema de compilación.

Todos los generadores de fuentes proporcionan una funcionalidad de sistema de compilación similar. Los tres casos de uso de generación de fuentes admitidos por el sistema de compilación son la generación de enlaces C mediante bindgen, interfaces AIDL e interfaces protobuf.

Cajas de fuente generada

Cada módulo de Rust que genera código fuente se puede utilizar como una caja, exactamente como si estuviera definido como una rust_library . (Esto significa que se puede definir como una dependencia en las propiedades rustlibs , rlibs y dylibs ). El mejor patrón de uso para el código de plataforma es emplear la fuente generada como una caja. ¡Aunque el include! La macro es compatible con el código fuente generado, su propósito principal es admitir código de terceros que reside en external/ .

Hay casos en los que el código de la plataforma aún puede usar el código fuente generado a través de la macro include!() , como cuando se usa un módulo genrule para generar el código fuente de una manera única.

Utilice include!() para incluir la fuente generada

El uso de la fuente generada como una caja se trata en los ejemplos de cada página de módulo específica (respectiva). Esta sección muestra cómo hacer referencia al código fuente generado a través de la macro include!() . Tenga en cuenta que este proceso es similar para todos los generadores de fuentes.

Requisito previo

Este ejemplo se basa en la suposición de que ha definido un módulo rust_bindgen ( libbuzz_bindgen ) y puede continuar con los Pasos para incluir la fuente generada para usar la macro include!() . Si no lo ha hecho, vaya a Definir un módulo Rust Bindgen , cree libbuzz_bindgen y luego regrese aquí.

Tenga en cuenta que las partes del archivo de compilación son aplicables a todos los generadores de origen.

Pasos para incluir la fuente generada

Cree external/rust/hello_bindgen/Android.bp con el siguiente contenido:

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",
    ],
}

Cree external/rust/hello_bindgen/src/bindings.rs con el siguiente contenido:

#![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"));

Cree external/rust/hello_bindgen/src/lib.rs con el siguiente contenido:

mod bindings;

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

¿Por qué cajas para la fuente generada?

A diferencia de los compiladores C/C++, rustc solo acepta un único archivo fuente que representa un punto de entrada a un binario o biblioteca. Espera que el árbol de fuentes esté estructurado de manera que todos los archivos de origen requeridos puedan descubrirse automáticamente. Esto significa que el código fuente generado debe colocarse en el árbol de código fuente o proporcionarse mediante una directiva de inclusión en el código fuente:

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

La comunidad de Rust depende de los scripts build.rs y de las suposiciones sobre el entorno de compilación de Cargo para trabajar con esta diferencia . Cuando se compila, el comando cargo establece una variable de entorno OUT_DIR en la que se espera que los scripts build.rs coloquen el código fuente generado. Utilice el siguiente comando para incluir el código fuente:

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

Esto presenta un desafío para Soong ya que las salidas de cada módulo se colocan en su propio directorio out/ ¹ . No hay un único OUT_DIR donde las dependencias generen su fuente generada.

Para el código de plataforma, AOSP prefiere empaquetar el código fuente generado en una caja que pueda importarse, por varias razones:

• Evite que los nombres de los archivos fuente generados colisionen.
• Reducir el código repetitivo registrado en todo el árbol que requiere mantenimiento. Cualquier texto estándar que sea necesario para compilar la fuente generada en una caja se puede mantener de forma centralizada.
• Evite interacciones ^implícitas entre el código generado y la caja circundante.
• Reduzca la presión sobre la memoria y el disco vinculando dinámicamente las fuentes generadas de uso común.

Como resultado, todos los tipos de módulos de generación de código fuente de Rust de Android producen código que se puede compilar y utilizar como una caja . Soong todavía admite cajas de terceros sin modificaciones si todas las dependencias fuente generadas para un módulo se copian en un único directorio por módulo, similar a Cargo. En tales casos, Soong establece la variable de entorno OUT_DIR en ese directorio al compilar el módulo, para que se pueda encontrar la fuente generada. Sin embargo, por los motivos ya descritos, se recomienda utilizar este mecanismo en el código de la plataforma únicamente cuando sea absolutamente necesario.

,

Esta página proporciona una vista de alto nivel de cómo se admite el código fuente generado y cómo se puede utilizar en el sistema de compilación.

Todos los generadores de fuentes proporcionan una funcionalidad de sistema de compilación similar. Los tres casos de uso de generación de fuentes admitidos por el sistema de compilación son la generación de enlaces C mediante bindgen, interfaces AIDL e interfaces protobuf.

Cajas de fuente generada

Cada módulo de Rust que genera código fuente se puede utilizar como una caja, exactamente como si estuviera definido como una rust_library . (Esto significa que se puede definir como una dependencia en las propiedades rustlibs , rlibs y dylibs ). El mejor patrón de uso para el código de plataforma es emplear la fuente generada como una caja. ¡Aunque el include! La macro es compatible con el código fuente generado, su propósito principal es admitir código de terceros que reside en external/ .

Hay casos en los que el código de la plataforma aún puede usar el código fuente generado a través de la macro include!() , como cuando usa un módulo genrule para generar el código fuente de una manera única.

Utilice include!() para incluir la fuente generada

El uso de la fuente generada como una caja se trata en los ejemplos de cada página de módulo específica (respectiva). Esta sección muestra cómo hacer referencia al código fuente generado a través de la macro include!() . Tenga en cuenta que este proceso es similar para todos los generadores de fuentes.

Requisito previo

Este ejemplo se basa en la suposición de que ha definido un módulo rust_bindgen ( libbuzz_bindgen ) y puede continuar con los Pasos para incluir la fuente generada para usar la macro include!() . Si no lo ha hecho, vaya a Definir un módulo Rust Bindgen , cree libbuzz_bindgen y luego regrese aquí.

Tenga en cuenta que las partes del archivo de compilación son aplicables a todos los generadores de origen.

Pasos para incluir la fuente generada

Cree external/rust/hello_bindgen/Android.bp con el siguiente contenido:

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",
    ],
}

Cree external/rust/hello_bindgen/src/bindings.rs con el siguiente contenido:

#![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"));

Cree external/rust/hello_bindgen/src/lib.rs con el siguiente contenido:

mod bindings;

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

¿Por qué cajas para la fuente generada?

A diferencia de los compiladores C/C++, rustc solo acepta un único archivo fuente que representa un punto de entrada a un binario o biblioteca. Espera que el árbol de fuentes esté estructurado de manera que todos los archivos de origen requeridos puedan descubrirse automáticamente. Esto significa que el código fuente generado debe colocarse en el árbol de código fuente o proporcionarse mediante una directiva de inclusión en el código fuente:

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

La comunidad de Rust depende de los scripts build.rs y de las suposiciones sobre el entorno de compilación de Cargo para trabajar con esta diferencia . Cuando se compila, el comando cargo establece una variable de entorno OUT_DIR en la que se espera que los scripts build.rs coloquen el código fuente generado. Utilice el siguiente comando para incluir el código fuente:

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

Esto presenta un desafío para Soong ya que las salidas de cada módulo se colocan en su propio directorio out/ ¹ . No hay un único OUT_DIR donde las dependencias generen su fuente generada.

Para el código de plataforma, AOSP prefiere empaquetar el código fuente generado en una caja que pueda importarse, por varias razones:

• Evite que los nombres de los archivos fuente generados colisionen.
• Reducir el código repetitivo registrado en todo el árbol que requiere mantenimiento. Cualquier texto estándar que sea necesario para compilar la fuente generada en una caja se puede mantener de forma centralizada.
• Evite interacciones ^implícitas entre el código generado y la caja circundante.
• Reduzca la presión sobre la memoria y el disco vinculando dinámicamente las fuentes generadas de uso común.

Como resultado, todos los tipos de módulos de generación de código fuente de Rust de Android producen código que se puede compilar y utilizar como una caja . Soong todavía admite cajas de terceros sin modificaciones si todas las dependencias fuente generadas para un módulo se copian en un único directorio por módulo, similar a Cargo. En tales casos, Soong establece la variable de entorno OUT_DIR en ese directorio al compilar el módulo, para que se pueda encontrar la fuente generada. Sin embargo, por los motivos ya descritos, se recomienda utilizar este mecanismo en el código de la plataforma únicamente cuando sea absolutamente necesario.

,

Esta página proporciona una vista de alto nivel de cómo se admite el código fuente generado y cómo se puede utilizar en el sistema de compilación.

Todos los generadores de fuentes proporcionan una funcionalidad de sistema de compilación similar. Los tres casos de uso de generación de fuentes admitidos por el sistema de compilación son la generación de enlaces C mediante bindgen, interfaces AIDL e interfaces protobuf.

Cajas de fuente generada

Cada módulo de Rust que genera código fuente se puede utilizar como una caja, exactamente como si estuviera definido como una rust_library . (Esto significa que se puede definir como una dependencia en las propiedades rustlibs , rlibs y dylibs ). El mejor patrón de uso para el código de plataforma es emplear la fuente generada como una caja. ¡Aunque el include! La macro es compatible con el código fuente generado, su objetivo principal es admitir código de terceros que reside en external/ .

Hay casos en los que el código de la plataforma aún puede usar el código fuente generado a través de la macro include!() , como cuando se usa un módulo genrule para generar el código fuente de una manera única.

Utilice include!() para incluir la fuente generada

El uso de la fuente generada como una caja se trata en los ejemplos de cada página de módulo específica (respectiva). Esta sección muestra cómo hacer referencia al código fuente generado a través de la macro include!() . Tenga en cuenta que este proceso es similar para todos los generadores de fuentes.

Requisito previo

Este ejemplo se basa en la suposición de que ha definido un módulo rust_bindgen ( libbuzz_bindgen ) y puede continuar con los Pasos para incluir la fuente generada para usar la macro include!() . Si no lo ha hecho, vaya a Definir un módulo Rust Bindgen , cree libbuzz_bindgen y luego regrese aquí.

Tenga en cuenta que las partes del archivo de compilación son aplicables a todos los generadores de origen.

Pasos para incluir la fuente generada

Cree external/rust/hello_bindgen/Android.bp con el siguiente contenido:

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",
    ],
}

Cree external/rust/hello_bindgen/src/bindings.rs con el siguiente contenido:

#![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"));

Cree external/rust/hello_bindgen/src/lib.rs con el siguiente contenido:

mod bindings;

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

¿Por qué cajas para la fuente generada?

A diferencia de los compiladores C/C++, rustc solo acepta un único archivo fuente que representa un punto de entrada a un binario o biblioteca. Espera que el árbol de fuentes esté estructurado de manera que todos los archivos de origen requeridos puedan descubrirse automáticamente. Esto significa que el código fuente generado debe colocarse en el árbol de código fuente o proporcionarse mediante una directiva de inclusión en el código fuente:

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

La comunidad de Rust depende de los scripts build.rs y de las suposiciones sobre el entorno de compilación de Cargo para trabajar con esta diferencia . Cuando se compila, el comando cargo establece una variable de entorno OUT_DIR en la que se espera que los scripts build.rs coloquen el código fuente generado. Utilice el siguiente comando para incluir el código fuente:

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

Esto presenta un desafío para Soong ya que las salidas de cada módulo se colocan en su propio directorio out/ ¹ . No hay un único OUT_DIR donde las dependencias generen su fuente generada.

Para el código de plataforma, AOSP prefiere empaquetar el código fuente generado en una caja que pueda importarse, por varias razones:

• Evite que los nombres de los archivos fuente generados colisionen.
• Reducir el código repetitivo registrado en todo el árbol que requiere mantenimiento. Cualquier texto estándar que sea necesario para compilar la fuente generada en una caja se puede mantener de forma centralizada.
• Evite interacciones ^implícitas entre el código generado y la caja circundante.
• Reduzca la presión sobre la memoria y el disco vinculando dinámicamente las fuentes generadas de uso común.

Como resultado, todos los tipos de módulos de generación de código fuente de Rust de Android producen código que se puede compilar y utilizar como una caja . Soong todavía admite cajas de terceros sin modificaciones si todas las dependencias fuente generadas para un módulo se copian en un único directorio por módulo, similar a Cargo. En tales casos, Soong establece la variable de entorno OUT_DIR en ese directorio al compilar el módulo, para que se pueda encontrar la fuente generada. Sin embargo, por los motivos ya descritos, se recomienda utilizar este mecanismo en el código de la plataforma únicamente cuando sea absolutamente necesario.