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 de ruta de acceso de origen/salida predefinidas

  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 de los archivos que denota esa etiqueta.



  Para los archivos fuente, esta es la ruta de acceso relativa a la raíz de tu espacio de trabajo.
  Para 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 de acceso 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 acceso de ejecución (que
 es la subruta de acceso debajo de la raíz) es testapp/empty.source. Esta
 es la ruta de acceso que pueden usar las acciones de compilación para encontrar el archivo.
    
    

      Los archivos de salida se organizan de manera similar, pero también tienen el prefijo de la subruta de acceso
      bazel-out/cpu-compilation_mode/bin (o para los resultados de las
      herramientas: bazel-out/cpu-opt-exec-hash/bin). 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 CPUs diferentes en
 la misma compilación sin que los resultados se superpongan.
    
    

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

  

    

      rootpath: Denota la ruta de acceso que un objeto 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 que corresponde 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 multiplataforma.
    

      Es similar a execpath pero quita los prefijos de configuración
 que se describieron anteriormente. En el ejemplo anterior, esto significa que tanto
      empty.source como app usan rutas de acceso relativas al espacio de trabajo puras: 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 "una sola 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 archivos de ejecución para encontrar una dependencia en el tiempo de ejecución, ya sea en el directorio de archivos de ejecución (si está disponible) o con el manifiesto de archivos de ejecución.
    
    

      Es similar a rootpath en el sentido de que no contiene
 prefijos de configuración, pero difiere en que siempre comienza con el
 nombre del repositorio. En el ejemplo anterior, esto significa que 
      empty.source y app dan como resultado 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 objeto binario y resolverla en una ruta de acceso del sistema de archivos con
      las bibliotecas de archivos de ejecución 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, incluso si el directorio de archivos de ejecución no está disponible.
    
    

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

  

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



  execpaths, rootpaths, rlocationpaths,
 y locations son las variaciones plurales de execpath,
 rootpath, rlocationpath, ylocation,
 respectivamente. Admiten etiquetas que producen varias salidas, en cuyo caso
 cada salida se muestra separada por un espacio. Las reglas de salida cero y las etiquetas con formato incorrecto
 producen errores de compilación.



  Todas las etiquetas a las que se hace referencia deben aparecer en srcs, los archivos de salida 
 o deps. De lo contrario, la compilación falla. 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 están bien.


Variables personalizadas


  Se puede hacer referencia a las variables "Make" personalizadas con cualquier atributo marcado como
  "Sujeto a la sustitución de 'Make variable'", 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 principal. Esto evita que Bazel tenga que cargar
 dependencias potencialmente costosas para proporcionar variables que los destinos de consumo no puedan
 usar.


Variables de la cadena de herramientas de C++

  Las 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
  ellas". Para admitir modos de compilación tan diversos como *SAN, ThinLTO,
 con o sin módulos, y objetos binarios cuidadosamente optimizados al mismo tiempo que
 pruebas de ejecución rápida en varias plataformas, las reglas integradas hacen todo lo posible para 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.



  Estas variables son un mecanismo de resguardo que los expertos en lenguajes pueden usar en
 casos excepcionales. Si tienes la tentación de usarlas, comunícate primero con los desarrolladores de Bazel.



  
ABI: La versión de ABI de C++. 

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

    
CC: 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 propio riesgo.
    
  
  
CC_FLAGS: Un conjunto mínimo de marcas para que el compilador de C/C++
 pueda usar genrules. En particular, contiene marcas para
 seleccionar la arquitectura correcta si CC admite varias
 arquitecturas.
  


  
 DUMPBIN: El volcado de archivos binarios COFF de Microsoft (dumpbin.exe) de
    Microsoft Visual Studio. 

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

  
 STRIP: El comando strip del mismo paquete que el compilador de C/C++



Variables de la cadena de herramientas de Java


  Las 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).



  No se debe usar directamente la mayoría de las herramientas del JDK. Las reglas integradas de Java
 usan enfoques mucho más sofisticados para la compilación y el empaquetado de Java
 que las herramientas ascendentes pueden expresar, 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 lenguajes pueden usar en
 casos excepcionales. Si tienes la tentación de usarlas, comunícate primero con los desarrolladores de Bazel.



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

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


Variables definidas por Starlark


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



  Consulta un ejemplo de variables definidas por Starlark.