Crear variables

mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion'
$(SRC)
genrule_srcs_expansion
) y, luego, usa "$$\{SRCS[@]}" en las líneas de comandos posteriores en lugar de $(SRCS). Una opción más sólida es escribir una regla de Starlark.



Variables predefinidas de ruta de acceso de entrada o salida

  Las variables predefinidas execpath, execpaths, rootpath, rootpaths, location y locations toman parámetros de etiqueta (p.ej., $(execpath
  //foo:bar)) y sustituyen las rutas de acceso a archivos indicadas por esa etiqueta.



  En el caso de los archivos fuente, esta es la ruta de acceso relativa a la raíz de tu espacio de trabajo.
  En el caso de los archivos que son resultados de reglas, esta es la ruta de acceso de salida del archivo (consulta la explicación de los archivos de salida a continuación).



  Consulta un ejemplo de variables de ruta predefinidas.


  

    

      execpath:  Denota la ruta de acceso debajo de execroot donde Bazel ejecuta acciones de compilación.
    
    

      En el ejemplo anterior, Bazel ejecuta todas las acciones de compilación en el directorio vinculado por el vínculo simbólico bazel-myproject en la raíz de tu espacio de trabajo. El archivo fuente empty.source está vinculado en la ruta de acceso bazel-myproject/testapp/empty.source. Por lo tanto, su ruta de ejecución (que es la subruta debajo de la raíz) es testapp/empty.source. Esta es la ruta de acceso que las acciones de compilación pueden usar para encontrar el archivo.
    
    

      Los archivos de salida se organizan de manera similar, pero también se les agrega el prefijo de la ruta de acceso secundaria bazel-out/cpu-compilation_mode/bin (o bazel-out/cpu-opt-exec-hash/bin para las salidas de las herramientas). En el ejemplo anterior, //testapp:app es una herramienta porque aparece en el atributo tools de show_app_output.
      Por lo tanto, su archivo de salida app se escribe en bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app.
      Por lo tanto, la ruta de acceso de ejecución es 
      bazel-out/cpu-opt-exec-hash/bin/testapp/app. Este prefijo adicional permite compilar el mismo destino para, por ejemplo, dos CPU diferentes en la misma compilación sin que los resultados se sobrescriban entre sí.
    
    

      La etiqueta que se pasa a esta variable debe representar exactamente un archivo. Para las etiquetas que representan archivos fuente, esto es verdadero automáticamente. En el caso de las etiquetas que representan reglas, la regla debe generar exactamente un resultado. Si es falso o la etiqueta no tiene el formato correcto, la compilación falla con un error.
    
  

  

    

      rootpath: Indica la ruta de acceso que un archivo binario compilado puede usar para encontrar una dependencia en el tiempo de ejecución en relación con el subdirectorio de su directorio de archivos de ejecución correspondiente al repositorio principal.
      Nota: Esto solo funciona si 
      --enable_runfiles está habilitado, lo que no sucede en Windows de forma predeterminada. En su lugar, usa rlocationpath para la compatibilidad con varias plataformas.
    

      Es similar a execpath, pero quita los prefijos de configuración descritos anteriormente. En el ejemplo anterior, esto significa que empty.source y app usan rutas puras relativas al espacio de trabajo: testapp/empty.source y testapp/app.
    
    

      El rootpath de un archivo en un repositorio externo repo comenzará con ../repo/, seguido de la ruta de acceso relativa al repositorio.
    
    

      Tiene los mismos requisitos de "solo una salida" que execpath.
    
  

  

    

      rlocationpath: Es la ruta de acceso que un objeto binario compilado puede pasar a la función 
      Rlocation de una biblioteca de runfiles para encontrar una dependencia en el tiempo de ejecución, ya sea en el directorio de runfiles (si está disponible) o con el manifiesto de runfiles.
    
    

      Es similar a rootpath, ya que no contiene prefijos de configuración, pero se diferencia en que siempre comienza con el nombre del repositorio. En el ejemplo anterior, esto significa que 
      empty.source y app generan las siguientes rutas de acceso: myproject/testapp/empty.source y 
      myproject/testapp/app.
    
    

      El rlocationpath de un archivo en un repositorio externo repo comenzará con repo/, seguido de la ruta de acceso relativa al repositorio.
    
    

      Pasar esta ruta de acceso a un archivo binario y resolverla en una ruta de acceso del sistema de archivos con las bibliotecas de runfiles es el enfoque preferido para encontrar dependencias en el tiempo de ejecución. En comparación con rootpath, tiene la ventaja de que funciona en todas las plataformas y, también, si el directorio de archivos ejecutables no está disponible.
    
    

      Tiene los mismos requisitos de "solo una salida" que execpath.
    
  

  

    location: Es un sinónimo de execpath o rootpath, según el atributo que se expanda. Este es un comportamiento heredado anterior a Starlark y no se recomienda, a menos que sepas realmente lo que hace para una regla en particular. Consulta #2475 para obtener más información.
  



  execpaths, rootpaths, rlocationpaths y locations son las variaciones en plural de execpath, rootpath, rlocationpath y location, respectivamente. Admiten etiquetas que producen varios resultados, en cuyo caso cada resultado se enumera separado por un espacio. Las reglas sin salida y las etiquetas con formato incorrecto producen errores de compilación.



  Todas las etiquetas a las que se hace referencia deben aparecer en los archivos de salida srcs o deps del destino de consumo. De lo contrario, la compilación fallará. Los destinos de C++ también pueden hacer referencia a etiquetas en data.



  Las etiquetas no tienen que estar en formato canónico: foo, :foo y //somepkg:foo son válidas.


Variables personalizadas


  Se puede hacer referencia a las variables "Make" personalizadas con cualquier atributo marcado como "Sujeto a sustitución de la variable Make", pero solo en los destinos que dependen de otros destinos que definen estas variables.



  Como práctica recomendada, todas las variables deben ser personalizadas, a menos que haya un motivo muy bueno para incorporarlas a Bazel Core. Esto evita que Bazel tenga que cargar dependencias potencialmente costosas para proporcionar variables que los objetivos que consumen no necesitan.


Variables de la cadena de herramientas de C++

  Los siguientes se definen en las reglas de la cadena de herramientas de C++ y están disponibles para cualquier regla que establezca toolchains =
  ["@bazel_tools//tools/cpp:toolchain_type"]. Algunas reglas, como java_binary, incluyen implícitamente la cadena de herramientas de C++ en su definición de regla. Heredan estas variables automáticamente.



  Las reglas integradas de C++ son mucho más sofisticadas que "ejecutar el compilador en él". Para admitir modos de compilación tan diversos como *SAN, ThinLTO, con o sin módulos, y archivos binarios cuidadosamente optimizados, además de pruebas de ejecución rápida en múltiples plataformas, las reglas integradas se esfuerzan por garantizar que se establezcan las entradas, las salidas y las marcas de línea de comandos correctas en cada una de las acciones generadas internamente, que pueden ser varias.



  Estas variables son un mecanismo de resguardo que los expertos en idiomas pueden usar en casos excepcionales. Si te sientes tentado a usarlos, primero comunícate con los desarrolladores de Bazel.



  
ABI: Es la versión de la ABI de C++. 

  
 AR: El comando "ar" de crosstool. 
  
 C_COMPILER:
    Es el identificador del compilador de C/C++, p.ej., llvm.
  
  

    
CC: Es el comando del compilador de C y C++.
    

      Te recomendamos que siempre uses CC_FLAGS en combinación con CC. Si no lo haces, será bajo tu propia responsabilidad.
    
  
  
CC_FLAGS: Es un conjunto mínimo de marcas para que el compilador de C/C++ pueda usarse con genrules. En particular, contiene marcas para seleccionar la arquitectura correcta si CC admite varias arquitecturas.
  


  
 DUMPBIN: Microsoft COFF Binary File Dumper (dumpbin.exe) de Microsoft Visual Studio. 

  
 NM: El comando "nm" de crosstool. 
  
 OBJCOPY: Es el comando objcopy del mismo conjunto que el compilador de C/C++. 

  
 STRIP: Es el comando strip del mismo conjunto que el compilador de C/C++.


Variables de la cadena de herramientas de Java


  Los siguientes se definen en las reglas de la cadena de herramientas de Java y están disponibles para cualquier regla que establezca toolchains =
["@rules_java//toolchains:current_java_runtime"] (o "@rules_java//toolchains:current_host_java_runtime" para el equivalente de la cadena de herramientas del host).



  La mayoría de las herramientas del JDK no deben usarse directamente. Las reglas integradas de Java usan enfoques mucho más sofisticados para la compilación y el empaquetado de Java que los que pueden expresar las herramientas upstream, como los Jars de interfaz, los Jars de interfaz de encabezado y las implementaciones de empaquetado y combinación de Jars altamente optimizadas.



  Estas variables son un mecanismo de resguardo que los expertos en idiomas pueden usar en casos excepcionales. Si te sientes tentado a usarlos, primero comunícate con los desarrolladores de Bazel.



  
 JAVA: El comando "java" (una máquina virtual de Java). Evita esto y, en su lugar, usa una regla java_binary siempre que sea posible. Puede ser una ruta de acceso relativa. Si debes cambiar de directorio antes de invocar java, debes capturar el directorio de trabajo antes de cambiarlo.
  

  
JAVABASE: Es el directorio base que contiene las utilidades de Java. Puede ser una ruta de acceso relativa. Tendrá un subdirectorio "bin".
  


Variables definidas por Starlark


  Los escritores de reglas y cadenas de herramientas pueden definir variables completamente personalizadas devolviendo un proveedor de TemplateVariableInfo. Cualquier regla que dependa de estos a través del atributo toolchains puede leer sus valores:



  Consulta un ejemplo de variables definidas por Starlark.