Archivos .bzl

Los atributos implícitos que comienzan con _ deben tener valores predeterminados y tener el tipo label o label_list.

Los atributos explícitos deben tener el tipo string y deben usar la restricción values. Los atributos explícitos restringen el aspecto para que se use solo con reglas que tengan atributos del mismo nombre, tipo y valores válidos según la restricción.

Una lista de proveedores no anidada se convertirá automáticamente en una lista que contiene una lista de proveedores. Es decir, [FooInfo, BarInfo] se convertirá automáticamente en [[FooInfo, BarInfo]].

Para que algunos objetivos de regla (p.ej., some_rule) sean visibles para un aspecto, some_rule debe anunciar todos los proveedores de, al menos, una de las listas de proveedores obligatorias. Por ejemplo, si el required_providers de un aspecto es [[FooInfo], [BarInfo], [BazInfo, QuxInfo]], este aspecto puede ver objetivos de some_rule solo si some_rule proporciona FooInfo, o BarInfo o ambos BazInfo y QuxInfo.

Una lista de proveedores no anidada se convertirá automáticamente en una lista que contiene una lista de proveedores. Es decir, [FooInfo, BarInfo] se convertirá automáticamente en [[FooInfo, BarInfo]].

Para que otro aspecto (p.ej., other_aspect) sea visible para este, other_aspect debe proporcionar todos los proveedores de al menos una de las listas. En el ejemplo de [[FooInfo], [BarInfo], [BazInfo, QuxInfo]], este aspecto puede ver other_aspect solo si other_aspect proporciona FooInfo o BarInfo o ambos BazInfo y QuxInfo.

Se generará un error si la función de implementación omite de su valor que se muestra alguno de los tipos de proveedores que se indican aquí. Sin embargo, la función de implementación puede mostrar proveedores adicionales que no se mencionan aquí.

Cada elemento de la lista es un objeto *Info que muestra provider(), con la excepción de que un proveedor heredado está representado por su nombre de cadena en su lugar.Cuando un destino de la regla se usa como una dependencia para un destino que declara un proveedor obligatorio, no es necesario especificar ese proveedor aquí. Basta con que la función de implementación lo muestre. Sin embargo, se considera una práctica recomendada especificarlo, aunque no es obligatorio. Sin embargo, el campo required_providers de un aspecto sí requiere que se especifiquen los proveedores aquí.

Por ejemplo, supongamos que un aspecto se propaga transitivamente a través del atributo `deps` y se aplica al objetivo `alpha`. Supongamos que `alpha` tiene `deps = [':beta_output']`, donde `beta_output` es un resultado declarado de un `beta` de destino. Supón que `beta` tiene un `charlie` de destino como uno de sus `alpha` de destino, y luego propaga el `false` a través del 'Aspecto'.

Falso de forma predeterminada.

• lista de campos:
  

  provider(fields = ['a', 'b'])

• nombre del campo del diccionario -> documentación:
  

  provider(
         fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })

A continuación, se incluye una descripción precisa. Consulta Reglas (inicialización personalizada de proveedores) para obtener un debate y casos de uso intuitivos.

Permite que P sea el símbolo del proveedor creado cuando se llama a provider(). Conceptualmente, una instancia de P se genera llamando a una función de constructor predeterminada c(*args, **kwargs), que hace lo siguiente:

• Si el campo args no está vacío, se produce un error.
• Si se especificó el parámetro fields cuando se llamó a provider() y si kwargs contiene alguna clave que no figure en fields, se produce un error.
• De lo contrario, c muestra una instancia nueva que tiene, para cada entrada k: v en kwargs, un campo llamado k con el valor v.

MyInfo = provider()
m = MyInfo(foo = 1)

Sin embargo, en el caso en el que se especifique init, la llamada a P(*args, **kwargs) realizará los siguientes pasos:

1. La devolución de llamada se invoca como init(*args, **kwargs), es decir, con los mismos argumentos posicionales y de palabras clave que se pasaron a P.
2. Se espera que el valor que se muestra de init sea un diccionario, d, cuyas claves son strings de nombres de campo. Si no es así, se produce un error.
3. Se genera una instancia nueva de P como si se llamara al constructor predeterminado con las entradas de d como argumentos de palabra clave, como en c(**d).

Nota: Los pasos anteriores implican que se produce un error si *args o **kwargs no coinciden con la firma de init, si falla la evaluación del cuerpo de init (quizás de manera intencional mediante una llamada a fail()) o si el valor que se muestra de init no es un diccionario con el esquema esperado.

De esta manera, la devolución de llamada init generaliza la construcción normal del proveedor, ya que permite argumentos posicionales y lógica arbitraria para el procesamiento previo y la validación. No permite eludir la lista de fields permitidos.

Cuando se especifica init, el valor que se muestra de provider() se convierte en una tupla (P, r), en la que r es el constructor sin procesar. De hecho, el comportamiento de r es exactamente el de la función de constructor predeterminada c que se analizó anteriormente. Por lo general, r está vinculado a una variable cuyo nombre tiene un prefijo de guion bajo para que solo el archivo .bzl actual tenga acceso directo a él:

MyInfo, _new_myinfo = provider(init = ...)

Un esquema para definir resultados declarados previamente. A diferencia de los atributos output y output_list, el usuario no especifica las etiquetas para estos archivos. Consulta la página Reglas para obtener más información sobre los resultados declarados previamente.

El valor de este argumento es un diccionario o una función de devolución de llamada que genera un diccionario. La devolución de llamada funciona de manera similar a los atributos de dependencias procesados: los nombres de los parámetros de la función se comparan con los atributos de la regla, por lo que, por ejemplo, si pasas outputs = _my_func con la definición def _my_func(srcs, deps): ..., la función tiene acceso a los atributos srcs y deps. Ya sea que el diccionario se especifique directamente o a través de una función, se interpreta de la siguiente manera:

Cada entrada en el diccionario crea un resultado declarado previamente en el que la clave es un identificador y el valor es una plantilla de string que determina la etiqueta de la salida. En la función de implementación de la regla, el identificador se convierte en el nombre de campo que se usa para acceder al File del resultado en ctx.outputs. La etiqueta del resultado tiene el mismo paquete que la regla, y la parte después del paquete se debe sustituir cada marcador de posición del formulario "%{ATTR}" por una cadena formada a partir del valor del atributo ATTR:

• Los atributos de tipo cadena se sustituyen literalmente.
• Los atributos de tipo de etiqueta se convierten en la parte de la etiqueta después del paquete, menos la extensión de archivo. Por ejemplo, la etiqueta "//pkg:a/b.c" se convierte en "a/b".
• Los atributos de tipo de salida se convierten en la parte de la etiqueta después del paquete, incluida la extensión de archivo (en el ejemplo anterior, "a/b.c").
• Todos los atributos de tipo de lista (por ejemplo, attr.label_list) que se usan en los marcadores de posición deben tener exactamente un elemento. Su conversión es la misma que la de su versión no lista (attr.label).
• Es posible que otros tipos de atributos no aparezcan en los marcadores de posición.
• Los marcadores de posición especiales que no son atributos %{dirname} y %{basename} se expanden a esas partes de la etiqueta de la regla y excluyen su paquete. Por ejemplo, en "//pkg:a/b.c", el dirname es a y el nombre base es b.c.

En la práctica, el marcador de posición de sustitución más común es "%{name}". Por ejemplo, para un destino llamado "foo", el dict de salida {"bin": "%{name}.exe"} declara previamente un resultado llamado foo.exe al que se puede acceder en la función de implementación como ctx.outputs.bin.

Se generará un error si la función de implementación omite de su valor que se muestra alguno de los tipos de proveedores que se indican aquí. Sin embargo, la función de implementación puede mostrar proveedores adicionales que no se mencionan aquí.

Cada elemento de la lista es un objeto *Info que muestra provider(), con la excepción de que un proveedor heredado está representado por su nombre de cadena en su lugar.Cuando un destino de la regla se usa como una dependencia para un destino que declara un proveedor obligatorio, no es necesario especificar ese proveedor aquí. Basta con que la función de implementación lo muestre. Sin embargo, se considera una práctica recomendada especificarlo, aunque no es obligatorio. Sin embargo, el campo required_providers de un aspecto sí requiere que se especifiquen los proveedores aquí.

Nota: Las reglas de prueba de análisis se definen principalmente con la infraestructura proporcionada en las bibliotecas principales de Starlark. Consulta Pruebas para obtener orientación.

Si una regla se define como una regla de prueba de análisis, puede usar las transiciones de configuración definidas mediante analysis_test_transition en sus atributos, pero tiene algunas restricciones:

• Los objetivos de esta regla están limitados en la cantidad de dependencias transitivas que pueden tener.
• La regla se considera una regla de prueba (como si se hubieran configurado test=True). Esto sustituye el valor de test
• La función de implementación de reglas no puede registrar acciones. En su lugar, debe registrar un resultado aprobado o reprobado proporcionando AnalysisTestResultInfo.

Se llama a la función en el momento de la carga para cada instancia de la regla. Se llama con name y los valores de los atributos públicos definidos por la regla (no con atributos genéricos, por ejemplo, tags).

Debe mostrar un diccionario desde los nombres de los atributos hasta los valores deseados. Los atributos que no se muestran no se ven afectados. Si se muestra None como valor, se usará el valor predeterminado especificado en la definición del atributo.

Los inicializadores se evalúan antes que los valores predeterminados especificados en una definición de atributo. En consecuencia, si un parámetro en la firma del inicializador contiene un valor predeterminado, reemplaza el valor predeterminado de la definición del atributo (excepto si se muestra None).

Del mismo modo, si un parámetro de la firma del inicializador no tiene un valor predeterminado, será obligatorio. En esos casos, se recomienda omitir la configuración obligatoria o predeterminada en una definición de atributo.

Se recomienda usar **kwargs para los atributos que no se controlan.

En el caso de las reglas extendidas, todos los inicializadores se denominan proceder del elemento secundario a los principales. A cada inicializador se le pasan solo los atributos públicos que conoce.

Las subreglas solo pueden tener atributos privados con tipo de etiqueta (es decir, etiqueta o lista de etiquetas). Bazel pasa automáticamente los valores resueltos correspondientes a estas etiquetas a la función de implementación de la subregla como argumentos con nombre (por lo tanto, la función de implementación es necesaria para aceptar los parámetros con nombre que coincidan con los nombres de los atributos). Los tipos de estos valores serán los siguientes:

• FilesToRunProvider para los atributos de etiqueta con executable=True
• File para los atributos de etiqueta con allow_single_file=True
• Target para todos los demás atributos de etiquetas
• [Target] para todos los atributos de la lista de etiquetas

Las especificaciones del paquete tienen el mismo formato que para package_group, excepto que no se permiten especificaciones de paquete negativas. Es decir, una especificación puede tener los siguientes formatos:

• "//foo": El paquete //foo
• "//foo/...": Es el paquete //foo y todos sus subpaquetes.
• "public" o "private": Todos los paquetes o ninguno, respectivamente.

No se permite la sintaxis "@". Todas las especificaciones se interpretan en relación con el repositorio del módulo actual.

Si value es una lista de cadenas, el conjunto de paquetes a los que se les otorgó visibilidad para este módulo es la unión de los paquetes representados por cada especificación. (Una lista vacía tiene el mismo efecto que private). Si value es una sola string, se trata como si fuera la lista singleton [value].

Ten en cuenta que las marcas --incompatible_package_group_has_public_syntax y --incompatible_fix_package_group_reporoot_syntax no tienen efecto en este argumento. Los valores "public" y "private" siempre están disponibles, y "//..." siempre se interpreta como "todos los paquetes del repositorio actual".